CVE-2026-45985

What it actually does

This is a Linux kernel ext4 filesystem flaw in the handling of unwritten extent splitting during direct I/O and writeback when the ext4 dioread_nolock behavior is enabled. Under a temporary ENOSPC condition while splitting an unwritten extent, the kernel can incorrectly mark an on-disk extent as written while the in-memory extent status tree still treats part of it as unwritten. If the subsequent I/O does not complete as expected and cached extent state is later dropped, stale on-disk data may become visible through the file. The practical impact is local, authenticated abuse that can cause filesystem data exposure or integrity inconsistency, and potentially operational disruption if applications rely on ext4 correctness under low-space write workloads.

Why it matters to the business

Systems using affected Linux kernels with ext4 filesystems may mishandle file contents during specific low-disk-space write patterns. In business terms, a local user or workload could trigger unexpected exposure of old data in files, application data inconsistency, or service instability tied to filesystem behavior. The risk is higher on multi-user Linux hosts, shared compute platforms, container hosts, build systems, databases, and storage-heavy application servers that use ext4 and experience frequent direct I/O, writeback, or low free-space conditions. Public exploitation is not currently known and EPSS is low, but kernel filesystem bugs should still be remediated through normal kernel patch cycles because exploitation does not require network access once local code execution is available.

How an attack unfolds

An attacker first needs the ability to run code locally or influence a local workload that writes to an ext4 filesystem. They create or target a file backed by an unwritten extent, then cause a direct I/O write to a subrange of that extent while the filesystem is operating with dioread_nolock behavior. The attacker also attempts to create temporary space pressure so that extent splitting fails with ENOSPC at the vulnerable point. Because the kernel incorrectly uses the conversion path before I/O is submitted, the on-disk extent can be marked written even though the extent status tree still tracks part of it as unwritten. If the direct I/O operation fails or does not populate the intended range, and later cache state is evicted, reads from the affected range may return stale data that should not have been exposed. The attack is local and timing/state dependent, but it can be automated by repeatedly creating sparse or unwritten extents, exhausting free space, issuing direct I/O writes, and reading back affected ranges after cache eviction or remount-like state changes.

How to fix it

Apply the Linux kernel update from the operating system or appliance vendor that includes the ext4 fix for this issue. No universal upstream package version was provided in the input, so use vendor advisories and fixed kernel changelogs to confirm that the ext4 change preventing EXT4_GET_BLOCKS_CONVERT during pre-I/O extent splitting is included. Prioritize patching systems that use ext4 for multi-user workloads, container storage, shared application storage, databases, CI/build workers, or hosts that frequently run close to full disk capacity. Where immediate patching is not possible, reduce exposure by avoiding ext4 dioread_nolock where feasible, maintaining adequate free space on ext4 filesystems, limiting untrusted local shell or workload execution, enforcing user and container isolation, and monitoring for repeated ENOSPC conditions on ext4-backed filesystems. Mitigations reduce likelihood but do not replace a kernel fix.

How to confirm the fix worked

Confirm the running kernel has been updated to a vendor build that includes the ext4 fix. Validate both the installed kernel package and the active booted kernel, because patching without rebooting leaves the vulnerable kernel in use. Review mount options for ext4 filesystems and identify any use of dioread_nolock or workloads that rely on direct I/O. Confirm free-space monitoring and alerting are active for ext4 filesystems to reduce the chance of triggering the vulnerable path. For exposure testing in non-production only, use a controlled ext4 filesystem and reproduce the preconditions: unwritten extents, partial-range direct I/O, and ENOSPC during extent splitting; after patching, stale data should not be exposed and filesystem state should remain consistent. Avoid destructive proof-of-concept testing on production filesystems.

Typical attack path

1. Gain local code execution or access to run an unprivileged workload on a Linux system using an affected kernel and ext4 filesystem.
2. Identify or create an ext4-backed file with unwritten extents, such as through fallocate-style allocation or application write patterns that create preallocated ranges.
3. Ensure the filesystem is using the vulnerable ext4 behavior, particularly workloads involving direct I/O or writeback with dioread_nolock enabled.
4. Create temporary disk-space pressure so an extent split can fail with ENOSPC during the vulnerable operation.
5. Issue a direct I/O write to only part of the unwritten extent, causing the kernel to split and convert extents before I/O submission.
6. Force or wait for the write to fail or remain incomplete, then cause extent status cache state to be dropped through memory pressure, inode eviction, remount, or normal cache aging.
7. Read the affected file range and check whether stale data from previous disk contents is exposed or whether filesystem/application behavior becomes inconsistent.

How to detect it

There is no reliable single log entry that proves exploitation, because the vulnerable behavior occurs inside normal filesystem extent handling and may only manifest as unexpected file contents. Investigate systems with affected kernels and ext4 filesystems for evidence of suspiciously induced low-space conditions, repeated allocation failures, direct I/O-heavy file activity, or application reports of stale or inconsistent file data. Useful log sources include kernel logs, system journal, syslog, auditd file activity logs if enabled, EDR telemetry for local processes performing high-volume file allocation and direct I/O, filesystem monitoring, and application logs from storage-intensive services. Look for repeated ENOSPC messages, ext4 warnings/errors, sudden filesystem space exhaustion followed by reads of preallocated files, unusual use of fallocate/truncate/dd or custom local binaries, and workload patterns that repeatedly create sparse/preallocated files and write only partial ranges. For forensics, preserve affected filesystems or block devices before repair where possible, compare application-level checksums or file histories, and examine whether stale data appears in file regions that should have been zeroed or newly written.

• dioread_nolock
• EXT4-fs error
• EXT4-fs warning
• No space left on device
• ENOSPC
• ext4_split_extent
• ext4_split_extent_at
• ext4_split_convert_extents
• ext4_map_blocks
• fallocate
• O_DIRECT

What your security team should do

• Inventory Linux systems using ext4 filesystems and identify those running kernels without the vendor fix.
• Prioritize patching multi-user systems, container hosts, shared compute nodes, storage-heavy application servers, and systems with frequent low-disk-space events.
• Reboot systems after kernel updates and verify the active kernel version, not only the installed package version.
• Review ext4 mount options and disable or avoid dioread_nolock where operationally feasible until patched.
• Strengthen disk capacity monitoring for ext4 filesystems and alert on repeated or sustained ENOSPC conditions.
• Restrict untrusted local code execution and enforce container/user isolation on systems that cannot be patched immediately.
• Review logs for ext4 errors, ENOSPC bursts, unexplained application data inconsistencies, or suspicious repeated file allocation and direct I/O activity.
• Do not treat the low EPSS score as a reason to ignore the issue on shared Linux infrastructure; local kernel filesystem flaws can become impactful when chained with separate initial-access vulnerabilities.