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.

No CVSS v4.0

No CVSS v3.1

No CVSS v3.0

No CVSS v2

This CVE is not in the KEV list.

No EPSS score available.

Key SSVC decision points have not yet been added.

Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).

Vendor Product Default status Versions
Linux Linux unaffected
Version Status Constraints
1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 affected < f0931a5c17005a0c4fc35bd1a001245effc3354b
1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 affected < d8ee559fccdef713f058cfe5f2c03dc9b18be3b1
1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 affected < c2ee51d684adca7645e4aa74adca13f6750390bc
1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 affected < a1b962a821e7a52d48212ae269b45808b4411267
1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 affected < 6d882ea3b0931b43530d44149b79fcd4ffc13030
0 affected < 6.6.130
0 affected < 6.12.75
0 affected < 6.18.14
0 affected < 6.19.4
Linux Linux affected
Version Status Constraints
6.6.130 unaffected ≤ 6.6.*
6.12.75 unaffected ≤ 6.12.*
6.18.14 unaffected ≤ 6.18.*
6.19.4 unaffected ≤ 6.19.*
7.0 unaffected ≤ *

No data.

No data.

OpenCVE Enrichment is a feature of OpenCVE that uses AI to automatically link vendors and products to CVEs. Learn more on GitHub.

No data.

Project Subscriptions

Vendors Products
Linux Subscribe
Linux Kernel Subscribe
Advisories

No advisories yet.

Fixes

Solution

No solution given by the vendor.

Workaround

No workaround given by the vendor.

References
Link Providers
https://git.kernel.org/stable/c/6d882ea3b0931b43530d44149b79fcd4ffc13030 cve-icon cve-icon
https://git.kernel.org/stable/c/a1b962a821e7a52d48212ae269b45808b4411267 cve-icon cve-icon
https://git.kernel.org/stable/c/c2ee51d684adca7645e4aa74adca13f6750390bc cve-icon cve-icon
https://git.kernel.org/stable/c/d8ee559fccdef713f058cfe5f2c03dc9b18be3b1 cve-icon cve-icon
https://git.kernel.org/stable/c/f0931a5c17005a0c4fc35bd1a001245effc3354b cve-icon cve-icon
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

Projects

Sign in to view the affected projects.

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-27T16:00:08Z

Weaknesses