PT-2026-43725 · Linux · Linux

Published

2026-05-27

·

Updated

2026-05-27

·

CVE-2026-45858

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: 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.

Related Identifiers

CVE-2026-45858

Affected Products

Linux