Linux Kernel EUVD-2026-86968

Requires: (1) local access to a host running the Linux kernel NTFS driver with write support; (2) an NTFS volume mounted read-write that the attacker can write to; (3) ability to invoke fallocate()/file extension on that volume (PR:L - write privilege on the mount); and critically (4) the underlying blkdev_issue_zeroout() zeroing operation must actually fail, which is an environmental/error condition not directly controllable by the attacker. Limiting factors that reduce real-world risk: no remote vector (local only), the NTFS write driver is uncommon on servers, and exploitation hinges on a block-device zeroing failure occurring during the allocation - absent that failure the vulnerable code path is never reached.

This is a low-priority, defense-in-depth fix rather than an urgent threat. All signals point the same low-risk direction: CVSS base score is 5.5 (Medium) with vector AV:L/AC:L/PR:L/UI:N - local, authenticated access required, no remote vector. EPSS is 0.14% (3rd percentile), the vulnerability is NOT on the CISA KEV list, and no public exploit code was identified. Exploitation status: no public exploit identified at time of analysis. There is a notable internal conflict in the input data: the provided CVSS vector encodes impact as C:N/I:N/A:H (pure availability), yet the description and the 'Information Disclosure' tag describe stale on-disk data being exposed in a completed write - that is a confidentiality/integrity concern, not an availability one. The A:H rating therefore appears mislabeled; the real-world harm is leakage of stale cluster contents, not denial of service - verify the impact metrics with NVD/vendor. Critically, the bug only manifests when an underlying zeroing I/O operation (blkdev_issue_zeroout) actually fails, which is not an attacker-controlled precondition, further lowering realistic exploitability. Net: a genuine kernel data-integrity fix worth patching in routine cycles, not an emergency.

A local user with write permission on a mounted NTFS volume calls fallocate() to extend a file at the moment the block device's zeroing operation fails (e.g., a transient I/O error). Because the failure was silently ignored, the newly allocated clusters are folded into initialized_size without being zeroed, so a subsequent read returns stale on-disk data that may contain another user's previously freed content. No public proof-of-concept exists, and triggering requires a genuine zeroing failure, making reliable exploitation difficult.