CVE-2026-45985

In the Linux kernel, the following vulnerability has been resolved:

ext4: don't set EXT4GETBLOCKS_CONVERT when splitting before submitting I/O

When allocating blocks during within-EOF DIO and writeback with dioreadnolock enabled, EXT4GETBLOCKSPREIO was set to split an existing large unwritten extent. However, EXT4GETBLOCKSCONVERT was set when calling ext4splitconvert_extents(), which may potentially result in stale data issues.

Assume we have an unwritten extent, and then DIO writes the second half.

[UUUUUUUUUUUUUUUU] on-disk extent U: unwritten extent [UUUUUUUUUUUUUUUU] extent status tree |<- ->| ----> dio write this range

First, ext4iomapalloc() call ext4mapblocks() with EXT4GETBLOCKSPREIO, EXT4GETBLOCKSUNWRITEXT and EXT4GETBLOCKSCREATE flags set. ext4mapblocks() find this extent and call ext4splitconvertextents() with EXT4GETBLOCKS_CONVERT and the above flags set.

Then, ext4splitconvertextents() calls ext4splitextent() with EXT4EXTMAYZEROOUT, EXT4EXTMARKUNWRIT2 and EXT4EXTDATAVALID2 flags set, and it calls ext4splitextentat() to split the second half with EXT4EXTDATAVALID2, EXT4EXTMARKUNWRIT1, EXT4EXTMAYZEROOUT and EXT4EXTMARKUNWRIT2 flags set. However, ext4splitextentat() failed to insert extent since a temporary lack -ENOSPC. It zeroes out the first half but convert the entire on-disk extent to written since the EXT4EXTDATA_VALID2 flag set, but left the second half as unwritten in the extent status tree.

[0000000000SSSSSS] data S: stale data, 0: zeroed [WWWWWWWWWWWWWWWW] on-disk extent W: written extent [WWWWWWWWWWUUUUUU] extent status tree

Finally, if the DIO failed to write data to the disk, the stale data in the second half will be exposed once the cached extent entry is gone.

Fix this issue by not passing EXT4GETBLOCKSCONVERT when splitting an unwritten extent before submitting I/O, and make ext4splitconvertextents() to zero out the entire extent range to zero for this case, and also mark the extent in the extent status tree for consistency.