CVE-2026-45892
Description
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.
Predictions
Heuristic predictions, AS-IS, for prioritization only.
Mitigations
Mitigation details
CVE-2026-45892 NameCVE-2026-45892 DescriptionIn 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…
CVE-2026-45892
| Name | CVE-2026-45892 |
| Description | 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. |
| Source | CVE (at NVD; CERT, ENISA, LWN, oss-sec, fulldisc, Debian ELTS, Red Hat, Ubuntu, Gentoo, SUSE bugzilla/CVE, GitHub advisories/code/issues, web search, more) |
Vulnerable and fixed packages
The table below lists information on source packages.
| Source Package | Release | Version | Status |
|---|---|---|---|
| linux (PTS) | bullseye | 5.10.223-1 | fixed |
| bullseye (security) | 5.10.257-1 | fixed | |
| bookworm | 6.1.170-3 | fixed | |
| bookworm (security) | 6.1.174-1 | fixed | |
| trixie | 6.12.86-1 | fixed | |
| trixie (security) | 6.12.90-2 | fixed | |
| forky | 7.0.9-1 | fixed | |
| sid | 7.0.10-1 | fixed |
The information below is based on the following data on fixed versions.
| Package | Type | Release | Fixed Version | Urgency | Origin | Debian Bugs |
|---|---|---|---|---|---|---|
| linux | source | (unstable) | (not affected) |
Notes
- linux <not-affected> (Vulnerable code not present)
Apply commands
- linux <not-affected> (Vulnerable code not present)OS impact
SUSE Affected 1 release
| Version | Status | Fixed in |
|---|---|---|
| — | Affected | — |
Windows Affected 1 release
| Version | Status | Fixed in |
|---|---|---|
| — | Affected | — |
Debian Fixed 5 releases
| Version | Status | Fixed in |
|---|---|---|
| trixie | Fixed | 6.12.85-1 |
| sid | Fixed | 6.18.14-1 |
| forky | Fixed | 6.18.14-1 |
| bullseye | Fixed | 0 |
| bookworm | Fixed | 0 |
References
- https://git.kernel.org/stable/c/f0931a5c17005a0c4fc35bd1a001245effc3354b
- https://git.kernel.org/stable/c/d8ee559fccdef713f058cfe5f2c03dc9b18be3b1
- https://git.kernel.org/stable/c/c2ee51d684adca7645e4aa74adca13f6750390bc
- https://git.kernel.org/stable/c/a1b962a821e7a52d48212ae269b45808b4411267
- https://git.kernel.org/stable/c/6d882ea3b0931b43530d44149b79fcd4ffc13030
- https://security-tracker.debian.org/tracker/CVE-2026-45892
- https://www.suse.com/security/cve/CVE-2026-45892.html
- https://git.kernel.org/stable/c/28db4bfc6f82fd20e2aadb7fc162244109a4eb31
- https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-45892
Community-verified mitigations for this CVE will appear above when contributors publish them.
Verify integrity in audit chain (admin only). AS-IS.