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: 5.5 Medium
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI 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 7.0, 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. Based on the description, it is inferred that the most likely attack vector would be local or privileged access, as the bug is in core kernel filesystem code. This could potentially give an attacker significant impact on data integrity and confidentiality.

Generated by OpenCVE AI on May 28, 2026 at 05:28 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply the latest Linux kernel update that removes the improper use of EXT4_GET_BLOCKS_CONVERT during extent splitting and ensures zeroing of unwritten extents before I/O, addressing the improper check or use of a flag (CWE-367).
  • Where immediate patching is not possible, disable direct I/O or switch to buffered writes for workloads that risk stale data exposure, limiting the potential for information disclosure.
  • Enable kernel audit logging for ext4 allocation errors and stale data conditions, and review logs for signs of this issue; supplement with security modules that enforce proper authentication for critical filesystem operations, mitigating missing authentication for critical functions.

Generated by OpenCVE AI on May 28, 2026 at 05:28 UTC.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Debian DLA Debian DLA DLA-4606-1 linux security update
History

Tue, 16 Jun 2026 14:15:00 +0000

Type Values Removed Values Added
Weaknesses NVD-CWE-noinfo
Metrics cvssV3_1

{'score': 7.0, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H'}

 cvssV3_1

{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}

Thu, 28 May 2026 04:15:00 +0000

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

Thu, 28 May 2026 00:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-367
References
Metrics threat_severity

None

 cvssV3_1

{'score': 7.0, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H'}

threat_severity

Moderate

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

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

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

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

Link: CVE-2026-45985

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Analyzed

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

Modified: 2026-06-16T14:05:15.997

Link: CVE-2026-45985

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-05-27T00:00:00Z

Links: CVE-2026-45985 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-05-28T05:30:06Z

Weaknesses