CVE-2026-45892

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 ext4splitextent() with the EXT4EXTMAYZEROOUT and EXT4EXTDATAVALID2 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

ext4splitextent() first try to split this extent at B with EXT4EXTDATAPARTIALVALID1 and EXT4EXTMAYZEROOUT flag set, but ext4splitextentat() 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

ext4splitextent() then try to split this extent at A with EXT4EXTDATA_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 ext4mapcreate_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.