PT-2026-43759 · Linux · Linux

Published

2026-05-27

·

Updated

2026-05-27

·

CVE-2026-45892

None

No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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.

Related Identifiers

CVE-2026-45892

Affected Products

Linux