Description
In the Linux kernel, the following vulnerability has been resolved:

ext4: don't zero the entire extent if EXT4_EXT_DATA_PARTIAL_VALID1

When allocating initialized blocks from a large unwritten extent, or
when splitting an unwritten extent during end I/O and converting it to
initialized, there is currently a potential issue of stale data if the
extent needs to be split in the middle.

0 A B N
[UUUUUUUUUUUU] U: unwritten extent
[--DDDDDDDD--] D: valid data
|<- ->| ----> this range needs to be initialized

ext4_split_extent() first try to split this extent at B with
EXT4_EXT_DATA_ENTIRE_VALID1 and EXT4_EXT_MAY_ZEROOUT flag set, but
ext4_split_extent_at() failed to split this extent due to temporary lack
of space. It zeroout B to N and mark the entire extent from 0 to N
as written.

0 A B N
[WWWWWWWWWWWW] W: written extent
[SSDDDDDDDDZZ] Z: zeroed, S: stale data

ext4_split_extent() then try to split this extent at A with
EXT4_EXT_DATA_VALID2 flag set. This time, it split successfully and left
a stale written extent from 0 to A.

0 A B N
[WW|WWWWWWWWWW]
[SS|DDDDDDDDZZ]

Fix this by pass EXT4_EXT_DATA_PARTIAL_VALID1 to ext4_split_extent_at()
when splitting at B, don't convert the entire extent to written and left
it as unwritten after zeroing out B to N. The remaining work is just
like the standard two-part split. ext4_split_extent() will pass the
EXT4_EXT_DATA_VALID2 flag when it calls ext4_split_extent_at() for the
second time, allowing it to properly handle the split. If the split is
successful, it will keep extent from 0 to A as unwritten.
Published: 2026-05-27
Score: 7.0 High
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The bug in ext4 occurs when the kernel splits a large unwritten extent, causing stale data that was previously written to remain accessible after a partial zero‑out operation. An attacker can read data that should have been discarded, exposing sensitive information that existed on the block device. This reflects an information exposure flaw coupled with stale data handling (CWE‑909).

Affected Systems

All Linux kernel builds that include the ext4 filesystem and have not incorporated the upstream patch fixing ext4_split_extent(). The description does not list specific kernel version numbers, so any kernel compiled before the commit was merged is potentially impacted, including distributions that have not yet released an updated package.

Risk and Exploitability

The CVSS score of 7.0 denotes a medium‑severity vulnerability. The EPSS score is very low, and the vulnerability is not listed in the CISA KEV catalog, suggesting limited active exploitation. Based on the description, it is inferred that exploitation requires a process that can read the block device involved, and no explicit privileged escalation is required. Successful exploitation would occur during normal read/write activity that triggers extent splitting, allowing the attacker to retrieve stale data that remains on disk after the partition operation.

Generated by OpenCVE AI on May 28, 2026 at 17:08 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade the Linux kernel to a version that incorporates the patched ext4 module (apply the latest distribution updates or compile the kernel from the upstream source with the fix).
  • If a kernel upgrade cannot be performed immediately, mount the ext4 filesystem on an encrypted block device (e.g., using dm‑crypt) so that any residual stale data is protected by cryptography.
  • Consider repeating regular zero‑out operations or rebuilding the filesystem with a fresh data area to eliminate stale blocks that may still reside on storage.

Generated by OpenCVE AI on May 28, 2026 at 17:08 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Thu, 28 May 2026 15:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-200

Thu, 28 May 2026 12:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-909
References
Metrics threat_severity

None

cvssV3_1

{'score': 7.0, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H'}

threat_severity

Important


Wed, 27 May 2026 19:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-200

Wed, 27 May 2026 14:15:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: ext4: don't zero the entire extent if EXT4_EXT_DATA_PARTIAL_VALID1 When allocating initialized blocks from a large unwritten extent, or when splitting an unwritten extent during end I/O and converting it to initialized, there is currently a potential issue of stale data if the extent needs to be split in the middle. 0 A B N [UUUUUUUUUUUU] U: unwritten extent [--DDDDDDDD--] D: valid data |<- ->| ----> this range needs to be initialized ext4_split_extent() first try to split this extent at B with EXT4_EXT_DATA_ENTIRE_VALID1 and EXT4_EXT_MAY_ZEROOUT flag set, but ext4_split_extent_at() failed to split this extent due to temporary lack of space. It zeroout B to N and mark the entire extent from 0 to N as written. 0 A B N [WWWWWWWWWWWW] W: written extent [SSDDDDDDDDZZ] Z: zeroed, S: stale data ext4_split_extent() then try to split this extent at A with EXT4_EXT_DATA_VALID2 flag set. This time, it split successfully and left a stale written extent from 0 to A. 0 A B N [WW|WWWWWWWWWW] [SS|DDDDDDDDZZ] Fix this by pass EXT4_EXT_DATA_PARTIAL_VALID1 to ext4_split_extent_at() when splitting at B, don't convert the entire extent to written and left it as unwritten after zeroing out B to N. The remaining work is just like the standard two-part split. ext4_split_extent() will pass the EXT4_EXT_DATA_VALID2 flag when it calls ext4_split_extent_at() for the second time, allowing it to properly handle the split. If the split is successful, it will keep extent from 0 to A as unwritten.
Title ext4: don't zero the entire extent if EXT4_EXT_DATA_PARTIAL_VALID1
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-05-30T10:41:40.719Z

Reserved: 2026-05-13T15:03:33.079Z

Link: CVE-2026-45858

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Awaiting Analysis

Published: 2026-05-27T14:16:57.943

Modified: 2026-05-27T14:48:31.480

Link: CVE-2026-45858

cve-icon Redhat

Severity : Important

Publid Date: 2026-05-27T00:00:00Z

Links: CVE-2026-45858 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-05-28T17:15:21Z

Weaknesses
  • CWE-909

    Missing Initialization of Resource