CVE-2026-72354

This is a use-after-free in the Linux NTFS driver's MFT writeback path. The vulnerability lives in the gap between what the code logically does and what memory safety actually requires. The developer acquired ni->runlist.lock, looked up the runlist element, released the lock, then read the rl->length and rl->v cn fields from that pointer. Between unlock and dereference, the $MFT allocation extension path can free and replace the runlist array. The writeback path is now dereferencing freed memory. The pattern is mechanically simple: lock, lookup, unlock, use. It passes every logical check a developer would run. There's no reversed conditional, no forgotten null check, no obvious error. What makes it vulnerable is that the pointer's lifetime ended at unlock, not at the last dereference. The developer held a borrowed reference across a lock boundary without recognizing that the borrow expired when the lock did. The fix is trivial: compute the remaining run length while holding the lock, store it as a scalar, then use the scalar after releasing the lock. This is a well-documented idiom in kernel development — return the value, not the reference. The challenge isn't knowing the fix; it's recognizing where the pattern applies. Two factors make this more dangerous than the CVSS 8.8 suggests. First, the race window is narrow but deterministic, not probabilistic. Any system performing sustained writes to an NTFS volume triggers MFT allocation extension as routine behavior, not exotic conditions. The race window isn't narrow in practice — it's open constantly. Second, the MFT is the filesystem's root of trust. Corruption doesn't just crash a writeback path; it corrupts the allocation structures governing every file on the volume. The NTFS driver runs as a Windows-compatibility layer in the Linux kernel, meaning successful exploitation could provide a kernel write primitive with implications beyond the immediate filesystem. You should audit your codebase for borrowed-pointer-across-lock-boundary patterns: anywhere lock-dropping is followed by pointer dereference, the question isn't 'is the pointer still valid' — it's 'why are we holding a pointer across a lock boundary at all.' The NTFS driver carries a specific maintenance burden as a reverse-engineered compatibility layer interfacing with Windows-internal data structures. Patterns that survived here may have persisted because the original Windows code had different concurrency assumptions that never got audited during the Linux port.

Reviewed through automated stages and approved by a human before publication.