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

ext4: drop extent cache after doing PARTIAL_VALID1 zeroout

When splitting an unwritten extent in the middle and converting it to
initialized in ext4_split_extent() with the EXT4_EXT_MAY_ZEROOUT and
EXT4_EXT_DATA_VALID2 flags set, it could leave a stale unwritten extent.

Assume we have an unwritten file and buffered write in the middle of it
without dioread_nolock enabled, it will allocate blocks as written
extent.

0 A B N
[UUUUUUUUUUUU] on-disk extent U: unwritten extent
[UUUUUUUUUUUU] extent status tree
[--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_PARTIAL_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 leave the entire extent as unwritten.

0 A B N
[UUUUUUUUUUUU] on-disk extent
[UUUUUUUUUUUU] extent status tree
[--DDDDDDDDZZ] Z: zeroed 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
leave an written extent from A to N.

0 A B N
[UUWWWWWWWWWW] on-disk extent W: written extent
[UUUUUUUUUUUU] extent status tree
[--DDDDDDDDZZ]

Finally ext4_map_create_blocks() only insert extent A to B to the extent
status tree, and leave an stale unwritten extent in the status tree.

0 A B N
[UUWWWWWWWWWW] on-disk extent W: written extent
[UUWWWWWWWWUU] extent status tree
[--DDDDDDDDZZ]

Fix this issue by always cached extent status entry after zeroing out
the second part.
Published: 2026-05-27
Score: n/a
EPSS: n/a
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

A flaw in the ext4 file system’s extent handling exposes a stale unwritten extent in the status tree after a partial zero‑out operation. The bug occurs when an unwritten file is split during a write; the kernel may leave behind an entry that still records the extent as unwritten, although the corresponding on‑disk data has been initialized. This inconsistency can cause subsequent read or write operations to observe corrupted or lost data, which directly impacts the reliability and integrity of stored files.

Affected Systems

The vulnerability is present in the Linux kernel’s ext4 implementation prior to the patch that removes the stale extent entry. All distributions that ship the kernel version containing this bug, regardless of release series, are affected until the kernel is updated to the fixed revision.

Risk and Exploitability

The exact CVSS score is not supplied, and the EPSS score is unavailable, so the exploitation probability cannot be quantified. The bug is a local‑system flaw that can be triggered by a user able to write to an unwritten file on an ext4 filesystem. Because it results in data corruption rather than code execution, the attack surface is limited to scenarios where the attacker can influence file contents, such as a privileged user or a compromised application. The fix is straightforward, and the vulnerability is not listed in the CISA KEV catalog, indicating no known widespread exploitation at this time.

Generated by OpenCVE AI on May 27, 2026 at 15:59 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade the Linux kernel to a version that includes the ext4 fix that removes stale unwritten extents after a zero‑out operation. This is the most reliable mitigation and should be performed promptly.
  • If a kernel upgrade is not immediately possible, restrict write access to unwritten files or avoid partial writes by using full‑block writes or applications that write whole files at once. This can reduce the likelihood of the bug being triggered.
  • Enable file system integrity monitoring (e.g., fsck on boot, or auditd checks) to detect unexpected data corruption early and trigger recovery or alerts.

Generated by OpenCVE AI on May 27, 2026 at 15:59 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

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

Type Values Removed Values Added
Weaknesses CWE-122
CWE-665

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: drop extent cache after doing PARTIAL_VALID1 zeroout When splitting an unwritten extent in the middle and converting it to initialized in ext4_split_extent() with the EXT4_EXT_MAY_ZEROOUT and EXT4_EXT_DATA_VALID2 flags set, it could leave a stale unwritten extent. Assume we have an unwritten file and buffered write in the middle of it without dioread_nolock enabled, it will allocate blocks as written extent. 0 A B N [UUUUUUUUUUUU] on-disk extent U: unwritten extent [UUUUUUUUUUUU] extent status tree [--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_PARTIAL_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 leave the entire extent as unwritten. 0 A B N [UUUUUUUUUUUU] on-disk extent [UUUUUUUUUUUU] extent status tree [--DDDDDDDDZZ] Z: zeroed 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 leave an written extent from A to N. 0 A B N [UUWWWWWWWWWW] on-disk extent W: written extent [UUUUUUUUUUUU] extent status tree [--DDDDDDDDZZ] Finally ext4_map_create_blocks() only insert extent A to B to the extent status tree, and leave an stale unwritten extent in the status tree. 0 A B N [UUWWWWWWWWWW] on-disk extent W: written extent [UUWWWWWWWWUU] extent status tree [--DDDDDDDDZZ] Fix this issue by always cached extent status entry after zeroing out the second part.
Title ext4: drop extent cache after doing PARTIAL_VALID1 zeroout
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:17:03.175Z

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

Link: CVE-2026-45892

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Awaiting Analysis

Published: 2026-05-27T14:17:03.353

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

Link: CVE-2026-45892

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-05-27T17:45:32Z

Weaknesses