Linux Kernel EUVD-2026-86969

Exploitation requires a Linux host mounting an NTFS volume read-write using the kernel NTFS driver, where that volume has already recorded a volume error (the description's reproducer is a $MFTMirr that does not match $MFT, which sets the error flag while leaving the mount read-write); a subsequent write plus a sync() then wrongly clears the on-disk dirty bit (observed as flags 0x0000 without the fix versus 0x0001 with it). Limiting factors: local access only (AV:L), low privileges but still authenticated (PR:L), the NTFS driver must be in use and the volume mounted read-write, and a pre-existing filesystem error must be present - the error condition is largely environmental rather than attacker-controllable, which sharply reduces practical exploitability.

All signals converge on this being a LOW-priority, low-real-world-risk issue. The provided CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H, base 5.5 MEDIUM) describes a local, authenticated, availability-only defect with no confidentiality or integrity impact in CVSS terms. EPSS reinforces this: 0.14% probability at the 3rd percentile indicates virtually no observed exploitation interest. There is no CISA KEV listing and no public exploit code referenced, so exploitation status is 'no public exploit identified at time of analysis.' No SSVC decision data was provided. The CWE is listed as N/A. One notable tension: the input Tags label this 'Information Disclosure,' but the CVSS vector sets C:N and the description describes a filesystem-recovery/data-integrity defect (dirty bit cleared so corruption is never repaired) - the tag contradicts the vector and the description, so treat 'Information Disclosure' as mislabeled. The realistic harm is silent non-repair of an already-damaged NTFS volume, a reliability/data-safety bug rather than an attacker-driven exploit; it is not a priority for emergency patching outside environments that mount NTFS read-write under Linux.

On a Linux host that has an NTFS volume mounted read-write, the volume records an internal error (for example $MFTMirr not matching $MFT). A local user with write access then performs any write and a sync(), which causes ntfs_sync_fs() to clear the on-disk dirty bit unconditionally, so the volume is marked clean despite the recorded error and recovery is never triggered. No public exploit code exists; this is a local, availability/data-integrity condition rather than a remotely weaponizable flaw.