In the Linux kernel, the following vulnerability has been resolved:
ext4: don't zero the entire extent if EXT4EXTDATAPARTIALVALID1
When allocating initialized blocks from a large unwritten extent, or when splitting an unwritten extent during end I/O and converting it to initialized, there is currently a potential issue of stale data if the extent needs to be split in the middle.
0 A B N
[UUUUUUUUUUUU] U: unwritten extent
[--DDDDDDDD--] D: valid data
|<- ->| ----> this range needs to be initialized
ext4splitextent() first try to split this extent at B with EXT4EXTDATAENTIREVALID1 and EXT4EXTMAYZEROOUT flag set, but ext4splitextentat() failed to split this extent due to temporary lack of space. It zeroout B to N and mark the entire extent from 0 to N as written.
0 A B N
[WWWWWWWWWWWW] W: written extent
[SSDDDDDDDDZZ] Z: zeroed, S: stale data
ext4splitextent() then try to split this extent at A with EXT4EXTDATA_VALID2 flag set. This time, it split successfully and left a stale written extent from 0 to A.
0 A B N
[WW|WWWWWWWWWW]
[SS|DDDDDDDDZZ]
Fix this by pass EXT4EXTDATAPARTIALVALID1 to ext4splitextentat() when splitting at B, don't convert the entire extent to written and left it as unwritten after zeroing out B to N. The remaining work is just like the standard two-part split. ext4splitextent() will pass the EXT4EXTDATAVALID2 flag when it calls ext4splitextent_at() for the second time, allowing it to properly handle the split. If the split is successful, it will keep extent from 0 to A as unwritten.
{
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/45xxx/CVE-2026-45858.json",
"cna_assigner": "Linux"
}