CVE-2026-45892

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