CVE-2026-45858

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: don&amp;#39;t zero the entire extent if EXT4_EXT_DATA_PARTIAL_VALID1<br /> <br /> When allocating initialized blocks from a large unwritten extent, or<br /> when splitting an unwritten extent during end I/O and converting it to<br /> initialized, there is currently a potential issue of stale data if the<br /> extent needs to be split in the middle.<br /> <br /> 0 A B N<br /> [UUUUUUUUUUUU] U: unwritten extent<br /> [--DDDDDDDD--] D: valid data<br /> || ----&gt; this range needs to be initialized<br /> <br /> ext4_split_extent() first try to split this extent at B with<br /> EXT4_EXT_DATA_ENTIRE_VALID1 and EXT4_EXT_MAY_ZEROOUT flag set, but<br /> ext4_split_extent_at() failed to split this extent due to temporary lack<br /> of space. It zeroout B to N and mark the entire extent from 0 to N<br /> as written.<br /> <br /> 0 A B N<br /> [WWWWWWWWWWWW] W: written extent<br /> [SSDDDDDDDDZZ] Z: zeroed, S: stale data<br /> <br /> ext4_split_extent() then try to split this extent at A with<br /> EXT4_EXT_DATA_VALID2 flag set. This time, it split successfully and left<br /> a stale written extent from 0 to A.<br /> <br /> 0 A B N<br /> [WW|WWWWWWWWWW]<br /> [SS|DDDDDDDDZZ]<br /> <br /> Fix this by pass EXT4_EXT_DATA_PARTIAL_VALID1 to ext4_split_extent_at()<br /> when splitting at B, don&amp;#39;t convert the entire extent to written and left<br /> it as unwritten after zeroing out B to N. The remaining work is just<br /> like the standard two-part split. ext4_split_extent() will pass the<br /> EXT4_EXT_DATA_VALID2 flag when it calls ext4_split_extent_at() for the<br /> second time, allowing it to properly handle the split. If the split is<br /> successful, it will keep extent from 0 to A as unwritten.