CVE-2026-45985: Linux Kernel Information Disclosure Flaw

CVE-2026-45985 Overview

CVE-2026-45985 is a Linux kernel vulnerability in the ext4 filesystem. The flaw resides in how ext4 handles unwritten extent splitting before submitting Direct I/O (DIO) and writeback operations with dioread_nolock enabled. When EXT4_GET_BLOCKS_CONVERT is incorrectly set during pre-I/O splitting of an unwritten extent, a subsequent allocation failure can leave inconsistent state between the on-disk extent and the extent status tree. The result is stale data exposure once cached extent entries are evicted. The vulnerability was published to the National Vulnerability Database on May 27, 2026.

Critical Impact
A failure path in ext4_split_extent_at() can convert an entire unwritten extent to written while leaving part of it tracked as unwritten in memory, exposing stale on-disk data to user-space readers after cache eviction.

Affected Products

Linux kernel — ext4 filesystem subsystem
Distributions and downstream kernels shipping the affected ext4 code paths
Systems mounting ext4 volumes with dioread_nolock enabled

Discovery Timeline

2026-05-27 - CVE-2026-45985 published to NVD
2026-05-27 - Last updated in NVD database

Technical Details for CVE-2026-45985

Vulnerability Analysis

The vulnerability affects ext4 block allocation during within-EOF Direct I/O and writeback when dioread_nolock is enabled. The kernel calls ext4_iomap_alloc(), which invokes ext4_map_blocks() with the EXT4_GET_BLOCKS_PRE_IO, EXT4_GET_BLOCKS_UNWRIT_EXT, and EXT4_GET_BLOCKS_CREATE flags. When an existing large unwritten extent must be split, ext4_split_convert_extents() is then called with EXT4_GET_BLOCKS_CONVERT also set. This flag should not be passed during pre-I/O splitting because the data has not yet been written.

The split path propagates EXT4_EXT_DATA_VALID2, EXT4_EXT_MARK_UNWRIT1, EXT4_EXT_MAY_ZEROOUT, and EXT4_EXT_MARK_UNWRIT2 flags into ext4_split_extent_at(). If extent insertion fails with -ENOSPC, the function zeroes the first half but, because of EXT4_EXT_DATA_VALID2, converts the entire on-disk extent to written. The extent status tree still marks the second half as unwritten. This is a file system inconsistency leading to information disclosure.

Root Cause

The root cause is the incorrect use of the EXT4_GET_BLOCKS_CONVERT flag when splitting an unwritten extent prior to I/O submission. The conversion semantics imply data has been written and may be safely marked written on disk, which is untrue during pre-I/O splitting. A failure to insert a new extent leaves on-disk metadata and the in-memory extent status tree desynchronized.

Attack Vector

The issue can be triggered by workloads that perform Direct I/O writes or writeback over partially unwritten extents on ext4 volumes mounted with dioread_nolock. A constrained-space condition causing -ENOSPC during extent splitting is required to trigger the inconsistent state. After the cached extent entry is evicted, a subsequent read of the affected range can return stale on-disk bytes from previously freed blocks, resulting in information disclosure to local users with read access to the file.

No public proof-of-concept exploit is referenced in the advisory. The fix removes EXT4_GET_BLOCKS_CONVERT from the pre-I/O split path, zeroes the entire extent range in ext4_split_convert_extents() for this case, and updates the extent status tree to keep both views consistent.

Detection Methods for CVE-2026-45985

Indicators of Compromise

Unexpected non-zero bytes returned when reading ranges of a file that should contain zeros or freshly allocated unwritten content.
dmesg warnings or filesystem inconsistencies reported by e2fsck involving extent flags and the extent status tree on ext4 volumes.
Workloads issuing heavy Direct I/O against ext4 mounted with dioread_nolock coinciding with -ENOSPC events in kernel logs.

Detection Strategies

Audit kernel versions across the fleet and compare against the fixed commits referenced in the kernel.org stable tree, including 2698731d2582, 2920ec61c98b, 37555690f39f, 67cdb7bd7442, 716e7439a5a9, 77e407967cd8, and feaf2a80e78f.
Enumerate ext4 mount options on hosts using mount or /proc/mounts and flag systems using dioread_nolock.
Correlate file integrity monitoring alerts with kernel ENOSPC events to detect possible stale-data exposure conditions.

Monitoring Recommendations

Track kernel package versions through endpoint telemetry and configuration management to confirm patch deployment.
Monitor /var/log/messages and journald for ext4 errors, extent corruption messages, and ENOSPC bursts.
Schedule offline e2fsck -fn validation during maintenance windows on storage volumes that experienced ENOSPC conditions.

How to Mitigate CVE-2026-45985

Immediate Actions Required

Update the Linux kernel to a version that includes the upstream ext4 fix referenced in the stable tree commits listed in the NVD advisory.
Inventory ext4 mounts that use dioread_nolock and prioritize patching those hosts first.
Provision sufficient free space on ext4 volumes to reduce the likelihood of -ENOSPC during extent splitting on unpatched kernels.

Patch Information

The ext4 maintainers resolved the issue by no longer passing EXT4_GET_BLOCKS_CONVERT when splitting unwritten extents before I/O submission. ext4_split_convert_extents() now zeroes the entire extent range in this code path and updates the extent status tree to maintain consistency. Patches are available in the Linux stable kernel tree commits, with additional fix references at commit 2920ec61c98b, commit 37555690f39f, commit 67cdb7bd7442, commit 716e7439a5a9, commit 77e407967cd8, and commit feaf2a80e78f.

Workarounds

Remount affected ext4 volumes without dioread_nolock until patched kernels can be deployed.
Avoid running workloads that mix Direct I/O writes with low free-space conditions on unpatched ext4 systems.
Apply distribution-provided kernel hotfixes as they become available from your vendor's security advisory channel.

bash

# Identify ext4 mounts using dioread_nolock and verify kernel version
grep ext4 /proc/mounts | grep dioread_nolock
uname -r
# Remount without dioread_nolock as a temporary mitigation
mount -o remount,dioread_lock /path/to/mount