CVE-2026-45858: ext4: don't zero the entire extent if EXT4_EXT_DATA_PARTIAL_VALID1

CVE-2026-45858: ext4: don't zero the entire extent if EXT4_EXT_DATA_PARTIAL_VALID1

[Greg Kroah-Hartman]

From: Greg Kroah-Hartman <gregkh@kernel.org>

Description
===========

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

ext4: don't zero the entire extent if EXT4_EXT_DATA_PARTIAL_VALID1

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

ext4_split_extent() first try to split this extent at B with
EXT4_EXT_DATA_ENTIRE_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 mark the entire extent from 0 to N
as written.

       0  A      B  N
       [WWWWWWWWWWWW]    W: written extent
       [SSDDDDDDDDZZ]    Z: zeroed, S: stale 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 left
a stale written extent from 0 to A.

       0  A      B   N
       [WW|WWWWWWWWWW]
       [SS|DDDDDDDDZZ]

Fix this by pass EXT4_EXT_DATA_PARTIAL_VALID1 to ext4_split_extent_at()
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. ext4_split_extent() will pass the
EXT4_EXT_DATA_VALID2 flag when it calls ext4_split_extent_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.

The Linux kernel CVE team has assigned CVE-2026-45858 to this issue.


Affected and fixed versions
===========================

	Fixed in 6.6.130 with commit 58ddae5d77b1db3a27b891c75a8fa120239ac092
	Fixed in 6.12.75 with commit d17857b4fb9ba5745b59be0ef38fd532991fccbf
	Fixed in 6.18.14 with commit d67c8ecf3d8fda9b8ef80e6f665d84b6d6ac9d88
	Fixed in 6.19.4 with commit 7015fcf473796e1d2d876f241bd9e0c36f3d4eef
	Fixed in 7.0 with commit 1bf6974822d1dba86cf11b5f05498581cf3488a2

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2026-45858
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	fs/ext4/extents.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/58ddae5d77b1db3a27b891c75a8fa120239ac092
	https://git.kernel.org/stable/c/d17857b4fb9ba5745b59be0ef38fd532991fccbf
	https://git.kernel.org/stable/c/d67c8ecf3d8fda9b8ef80e6f665d84b6d6ac9d88
	https://git.kernel.org/stable/c/7015fcf473796e1d2d876f241bd9e0c36f3d4eef
	https://git.kernel.org/stable/c/1bf6974822d1dba86cf11b5f05498581cf3488a2