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: n/a
EPSS: n/a
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The vulnerability occurs in the ext4 filesystem when a large unwritten extent is split. Instead of properly zeroing or preserving the stale portion, the kernel incorrectly marks the whole extent as written after a partial zero‑out. This results in stale, previously written data remaining accessible in the new extent. The flaw allows an attacker to read data that should have been discarded, effectively leaking sensitive information that lived in the blocks before the split operation. The weakness corresponds to poor handling of uninitialized or stale data and can lead to confidentiality violations.

Affected Systems

All Linux kernel installations that have the ext4 filesystem and have not applied the upstream patch that fixes ext4_split_extent(). The specific patch versions are not enumerated here, but any kernel built from source before the merging of the described commit is susceptible. Users of standard distribution kernels that have not yet incorporated the fix should be considered affected.

Risk and Exploitability

The vulnerability can be exploited when the filesystem performs I/O operations that involve large unwritten extents, such as mounting a fresh filesystem or writing large files, or during normal read/write cycles that trigger extent splitting. Because the flaw is in the kernel's internal extent management, local privilege escalation is not required; any process able to read the affected block device can potentially read the stale data. However, no public exploit is documented and the EPSS score is not available, indicating the likelihood of widespread exploitation is low. The vulnerability is not listed in CISA's KEV catalog, further suggesting limited attacker interest.

Generated by OpenCVE AI on May 27, 2026 at 19:05 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade the Linux kernel to a version that includes the patched ext4 module (apply the latest distribution updates or build from upstream with the fix).
  • If an immediate kernel upgrade is not possible, consider remounting the affected ext4 filesystems with data protection policies and ensuring regular disk zeroing or use of encrypted filesystems to mitigate stale data leakage.
  • If feasible, enable filesystem level encryption (e.g., dm‑crypt) so that any residual stale data is cryptographically protected and inaccessible to unprivileged attackers.

Generated by OpenCVE AI on May 27, 2026 at 19:05 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

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-27T12:15:37.738Z

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

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-05-27T19:15:26Z

Weaknesses