Linux Kernel CVE-2026-45985

Exploitation requires an ext4 filesystem explicitly mounted with the 'dioread_nolock' option (not enabled by default in most Linux distributions; commonly configured for O_DIRECT performance in database workloads such as MySQL, PostgreSQL, or Oracle on ext4). Within that environment, three additional conditions must align: the target file must contain an existing large unwritten extent (typical during file pre-allocation or fallocate scenarios), a Direct I/O write must cover only a portion of that extent (within-EOF write), and the filesystem must encounter an -ENOSPC error precisely during the ext4_split_extent_at() call followed by a DIO write failure that prevents data from committing. Local filesystem write access with at least unprivileged user privileges (PR:L per CVSS) is required; no network access or user interaction is needed. The stale data window is limited to the affected extent region and only opens after the extent status tree cache entry is evicted. Systems not using dioread_nolock, and filesystems other than ext4, are fully unaffected.

The vendor CVSS 3.1 score of 5.5 (Medium) with vector AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H classifies this as a local availability-only issue, but this conflicts with two other data points: the NVD 'Information Disclosure' tag and the CVE description's explicit stale-data exposure scenario, which implies at minimum a low-level confidentiality impact. EPSS at 0.02% (7th percentile) and absence from CISA KEV both confirm no observed automated or widespread exploitation. The AC:L assignment in the vendor vector understates real complexity: reliable triggering requires ext4 mounted with dioread_nolock (non-default on most general-purpose distributions, but commonly enabled on database servers using O_DIRECT), an ENOSPC condition occurring precisely during extent split, and a subsequent DIO write failure - three independently unlikely conditions that must align. For storage-sensitive environments such as database servers or virtual machine image stores on ext4 with dioread_nolock, the data integrity risk is non-trivial despite the low EPSS, and patching is warranted. For general-purpose desktops or servers not using dioread_nolock, this vulnerability poses negligible operational risk.

A local user with write access to a file on an ext4 filesystem mounted with dioread_nolock initiates a Direct I/O write that covers only the second half of an existing large unwritten extent. If the underlying storage is near-full so that an ENOSPC error occurs during ext4_split_extent_at() and the DIO write subsequently fails to commit, the on-disk extent is left in written state while the extent status tree marks the second half as unwritten - once the in-memory cache entry is evicted, a subsequent read of the second-half region returns stale pre-zero data from a prior file version. No public proof-of-concept code has been identified at time of analysis, and reliable reproduction requires precise timing of storage pressure with DIO write failure.