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 ext4_split_extent() with the EXT4_EXT_MAY_ZEROOUT and

EXT4_EXT_DATA_VALID2 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

ext4_split_extent() first try to split this extent at B with

EXT4_EXT_DATA_PARTIAL_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 leave the entire extent as unwritten.

0 A B N

[UUUUUUUUUUUU] on-disk extent

[UUUUUUUUUUUU] extent status tree

[--DDDDDDDDZZ] Z: zeroed 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

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