CVE-2026-45985 - Vulnerability Details

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

Description

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

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

When allocating blocks during within-EOF DIO and writeback with
dioread_nolock enabled, EXT4_GET_BLOCKS_PRE_IO was set to split an
existing large unwritten extent. However, EXT4_GET_BLOCKS_CONVERT was
set when calling ext4_split_convert_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, ext4_iomap_alloc() call ext4_map_blocks() with
EXT4_GET_BLOCKS_PRE_IO, EXT4_GET_BLOCKS_UNWRIT_EXT and
EXT4_GET_BLOCKS_CREATE flags set. ext4_map_blocks() find this extent and
call ext4_split_convert_extents() with EXT4_GET_BLOCKS_CONVERT and the
above flags set.

Then, ext4_split_convert_extents() calls ext4_split_extent() with
EXT4_EXT_MAY_ZEROOUT, EXT4_EXT_MARK_UNWRIT2 and EXT4_EXT_DATA_VALID2
flags set, and it calls ext4_split_extent_at() to split the second half
with EXT4_EXT_DATA_VALID2, EXT4_EXT_MARK_UNWRIT1, EXT4_EXT_MAY_ZEROOUT
and EXT4_EXT_MARK_UNWRIT2 flags set. However, ext4_split_extent_at()
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 EXT4_EXT_DATA_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 EXT4_GET_BLOCKS_CONVERT when splitting
an unwritten extent before submitting I/O, and make
ext4_split_convert_extents() to zero out the entire extent range
to zero for this case, and also mark the extent in the extent status
tree for consistency.

Published: 2026-05-27

Score: n/a

EPSS: n/a

KEV: No

Impact:

Action:

Analysis

Impact

In the Linux kernel, the ext4 file system incorrectly sets a conversion flag when splitting an unwritten extent during direct I/O or writeback with dioread_nolock enabled. This causes the on‑disk extent to be marked as written while the extent status tree still references it as unwritten, leaving stale data in the buffer cache if the physical write subsequently fails. An attacker who can influence DIO writes may read this stale data, resulting in data integrity loss or sensitive information disclosure.

Affected Systems

All Linux kernels that use the ext4 filesystem are potentially affected. No specific kernel version is listed, so any installation that has this ext4 bug remains at risk until corrected by a kernel update.

Risk and Exploitability

The CVSS score is not provided, the EPSS score is unavailable, and the vulnerability is not listed in the CISA KEV catalog. The flaw requires the attacker to trigger a direct I/O write that spans an unwritten extent and then cause that write to fail. Because the bug is in core kernel filesystem code, local or privileged access is the most likely attack vector, potentially giving an attacker significant impact on data integrity and confidentiality.

Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).

Vendor Product Default status Versions

Linux

unaffected

Version	Status	Constraints
`b8a8684502a0fc852afa0056c6bb2a9273f6fcc0`	affected	< 77e407967cd872cd75d7e4a691908e49c8e6b4d4
`b8a8684502a0fc852afa0056c6bb2a9273f6fcc0`	affected	< 37555690f39f78ef69af347d9aff897e07445949
`b8a8684502a0fc852afa0056c6bb2a9273f6fcc0`	affected	< 67cdb7bd7442bd3cdc6d6088bbb2df9be2fe936c
`b8a8684502a0fc852afa0056c6bb2a9273f6fcc0`	affected	< 2920ec61c98b9476781359f05b94da84e80f54d4
`b8a8684502a0fc852afa0056c6bb2a9273f6fcc0`	affected	< 2698731d25823267c29190cb578da9296a0c0d7b
`b8a8684502a0fc852afa0056c6bb2a9273f6fcc0`	affected	< 716e7439a5a9b18c3ff882c2f8c834b9ced1aaec
`b8a8684502a0fc852afa0056c6bb2a9273f6fcc0`	affected	< feaf2a80e78f89ee8a3464126077ba8683b62791

Linux

affected

Version	Status	Constraints
`3.15`	affected	—
`0`	unaffected	< 3.15
`5.10.253`	unaffected	≤ 5.10.*
`5.15.203`	unaffected	≤ 5.15.*
`6.6.130`	unaffected	≤ 6.6.*
`6.12.77`	unaffected	≤ 6.12.*
`6.18.17`	unaffected	≤ 6.18.*
`6.19.4`	unaffected	≤ 6.19.*
`7.0`	unaffected	≤ *

No data.

Vendor Product Confidence Versions

Linux

Linux Kernel

99%

Version	Status	Scheme	Platform
`[b8a8684502a0fc852afa0056c6bb2a9273f6fcc0,77e407967cd872cd75d7e4a691908e49c8e6b4d4)`	affected	code_commit	—
`[b8a8684502a0fc852afa0056c6bb2a9273f6fcc0,37555690f39f78ef69af347d9aff897e07445949)`	affected	code_commit	—
`[b8a8684502a0fc852afa0056c6bb2a9273f6fcc0,67cdb7bd7442bd3cdc6d6088bbb2df9be2fe936c)`	affected	code_commit	—
`[b8a8684502a0fc852afa0056c6bb2a9273f6fcc0,2920ec61c98b9476781359f05b94da84e80f54d4)`	affected	code_commit	—
`[b8a8684502a0fc852afa0056c6bb2a9273f6fcc0,2698731d25823267c29190cb578da9296a0c0d7b)`	affected	code_commit	—
`[b8a8684502a0fc852afa0056c6bb2a9273f6fcc0,716e7439a5a9b18c3ff882c2f8c834b9ced1aaec)`	affected	code_commit	—
`[b8a8684502a0fc852afa0056c6bb2a9273f6fcc0,feaf2a80e78f89ee8a3464126077ba8683b62791)`	affected	code_commit	—

Linux

Linux Kernel

99%

Version	Status	Scheme	Platform
`3.15`	affected	generic	—
`[0,3.15)`	unaffected	generic	—
`[5.10.253,5.11.0)`	unaffected	semver	—
`[5.15.203,5.16.0)`	unaffected	semver	—
`[6.6.130,6.7.0)`	unaffected	semver	—
`[6.12.77,6.13.0)`	unaffected	semver	—
`[6.18.17,6.19.0)`	unaffected	semver	—
`[6.19.4,6.20.0)`	unaffected	semver	—
`[7.0,*]`	unaffected	generic	—

Found an issue or want to improve our Enrichment? You can suggest it directly by opening an issue on our dedicated GitHub repository .

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

Apply the latest Linux kernel patch that removes the use of EXT4_GET_BLOCKS_CONVERT during extent splitting and zeroes unwritten extents before I/O.
Disable direct I/O (DIO) or switch to buffered writes for critical workloads until the kernel update is deployed.
Configure kernel audit logging to flag ext4 allocation errors or stale data conditions, and review logs for indications of the issue.

Generated by OpenCVE AI on May 27, 2026 at 17:09 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

No CVSS v4.0

No CVSS v3.1

No CVSS v3.0

No CVSS v2

This CVE is not in the KEV list.

No EPSS score available.

Key SSVC decision points have not yet been added.

References

Link	Providers
https://git.kernel.org/stable/c/2698731d25823267c29190cb578da9296a0c0d7b
https://git.kernel.org/stable/c/2920ec61c98b9476781359f05b94da84e80f54d4
https://git.kernel.org/stable/c/37555690f39f78ef69af347d9aff897e07445949
https://git.kernel.org/stable/c/67cdb7bd7442bd3cdc6d6088bbb2df9be2fe936c
https://git.kernel.org/stable/c/716e7439a5a9b18c3ff882c2f8c834b9ced1aaec
https://git.kernel.org/stable/c/77e407967cd872cd75d7e4a691908e49c8e6b4d4
https://git.kernel.org/stable/c/feaf2a80e78f89ee8a3464126077ba8683b62791

History

Wed, 27 May 2026 17:30:00 +0000

Type	Values Removed	Values Added
Weaknesses		CWE-200 CWE-346

Wed, 27 May 2026 14:15:00 +0000

Type	Values Removed	Values Added
Description		In the Linux kernel, the following vulnerability has been resolved: ext4: don't set EXT4_GET_BLOCKS_CONVERT when splitting before submitting I/O When allocating blocks during within-EOF DIO and writeback with dioread_nolock enabled, EXT4_GET_BLOCKS_PRE_IO was set to split an existing large unwritten extent. However, EXT4_GET_BLOCKS_CONVERT was set when calling ext4_split_convert_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, ext4_iomap_alloc() call ext4_map_blocks() with EXT4_GET_BLOCKS_PRE_IO, EXT4_GET_BLOCKS_UNWRIT_EXT and EXT4_GET_BLOCKS_CREATE flags set. ext4_map_blocks() find this extent and call ext4_split_convert_extents() with EXT4_GET_BLOCKS_CONVERT and the above flags set. Then, ext4_split_convert_extents() calls ext4_split_extent() with EXT4_EXT_MAY_ZEROOUT, EXT4_EXT_MARK_UNWRIT2 and EXT4_EXT_DATA_VALID2 flags set, and it calls ext4_split_extent_at() to split the second half with EXT4_EXT_DATA_VALID2, EXT4_EXT_MARK_UNWRIT1, EXT4_EXT_MAY_ZEROOUT and EXT4_EXT_MARK_UNWRIT2 flags set. However, ext4_split_extent_at() 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 EXT4_EXT_DATA_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 EXT4_GET_BLOCKS_CONVERT when splitting an unwritten extent before submitting I/O, and make ext4_split_convert_extents() to zero out the entire extent range to zero for this case, and also mark the extent in the extent status tree for consistency.
Title		ext4: don't set EXT4_GET_BLOCKS_CONVERT when splitting before submitting I/O
First Time appeared		Linux Linux linux Kernel
CPEs		cpe:2.3:o:linux:linux_kernel::::::::
Vendors & Products		Linux Linux linux Kernel
References		https://git.kernel.org/stable/c/2698731d25823267c29190cb578da9296a0c0d7b https://git.kernel.org/stable/c/2920ec61c98b9476781359f05b94da84e80f54d4 https://git.kernel.org/stable/c/37555690f39f78ef69af347d9aff897e07445949 https://git.kernel.org/stable/c/67cdb7bd7442bd3cdc6d6088bbb2df9be2fe936c https://git.kernel.org/stable/c/716e7439a5a9b18c3ff882c2f8c834b9ced1aaec https://git.kernel.org/stable/c/77e407967cd872cd75d7e4a691908e49c8e6b4d4 https://git.kernel.org/stable/c/feaf2a80e78f89ee8a3464126077ba8683b62791

Subscriptions

Linux Linux Kernel

MITRE

Status: PUBLISHED

Assigner: Linux

Published: 2026-05-27T12:18:43.844Z

Updated: 2026-05-27T12:18:43.844Z

Reserved: 2026-05-13T15:03:33.090Z

Link: CVE-2026-45985

Vulnrichment

No data.

NVD

Status : Awaiting Analysis

Published: 2026-05-27T14:17:15.820

Modified: 2026-05-27T14:48:03.013

Link: CVE-2026-45985

Redhat

No data.

OpenCVE Enrichment

Updated: 2026-05-27T21:15:25Z

Weaknesses

Impact

Affected Systems

Risk and Exploitability

Tracking

Subscriptions

JSON object

JSON object

JSON object

JSON object

JSON object