Cloudanix VulnDB

CVE-2026-99241

None

CVSS

—

EPSS

0.2%

Published

Nov 2, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A missing lock in the Linux NTFS driver can let simultaneous file operations interfere with each other, risking corrupted files or system crashes on affected machines.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Data Tampering
Component
OS kernel
Class
Race Condition
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Race condition in ntfs_filemap_page_mkwrite allows concurrent truncate/fallocate to invalidate pagecache and rewrite runlists while write faults map blocks and dirty folios, violating required serialization around iomap_page_mkwrite.

Why it matters to the business

Systems using NTFS filesystems on Linux may experience data corruption, inconsistent on-disk state, or kernel crashes during heavy concurrent file writes and space management operations, with elevated urgency due to public disclosure one day ago.

How an attack unfolds

A local attacker triggers concurrent file write faults via mmap while another process performs truncate, fallocate, punch-hole, or collapse operations; the missing invalidate_lock allows the fault handler to map blocks against a stale runlist that is later modified, leading to use-after-free or data corruption scenarios.

How to fix it

Apply the upstream kernel patch that wraps iomap_page_mkwrite with invalidate_lock shared; rebuild and deploy updated kernel packages containing the fix for all affected distributions.

How to confirm the fix worked

Confirm presence of invalidate_lock acquisition around iomap_page_mkwrite in ntfs_filemap_page_mkwrite by inspecting kernel source or checking for updated package versions that include the locking change.

Typical attack path

  1. Map a file region writable via mmap in one thread
  2. Trigger write fault on the mapped page
  3. Concurrently invoke fallocate or truncate from another process
  4. Race window allows runlist modification without lock held during block mapping
  5. Resulting inconsistent state leads to corruption or crash on subsequent I/O

How to detect it

Review kernel logs for NTFS-related warnings or oops during file operations involving mmap and fallocate; inspect audit logs for sequences of truncate and write syscalls on the same NTFS file descriptors.

What your security team should do

  • Prioritize kernel updates on all Linux systems mounting NTFS volumes within the next patch cycle
  • Monitor for kernel oops or filesystem errors on NTFS mounts as immediate indicators of exposure
  • Restrict untrusted local code execution on systems with NTFS mounts until patched

The record

In the Linux kernel, the following vulnerability has been resolved: ntfs: take invalidate_lock in ntfs_filemap_page_mkwrite() ntfs_filemap_page_mkwrite() calls iomap_page_mkwrite() without holding mapping->invalidate_lock, so a concurrent truncate or fallocate can be in the middle of invalidating pagecache and rewriting the runlist while the write fault maps blocks and dirties the folio. This races with ntfs_attr_fallocate(), which merges clusters into the in-memory runlist, drops the runlist lock, and only afterwards zeroes the newly allocated clusters on disk; and with the punch-hole/insert/collapse paths that free clusters after truncating the cache. Per Documentation/filesystems/locking.rst, ->page_mkwrite() must ensure there are no truncate/invalidate races, "usually mapping->invalidate_lock is suitable for proper serialization". xfs takes its mmaplock (= the invalidate_lock rwsem) shared in exactly this path. Take invalidate_lock shared around iomap_page_mkwrite(). The read-only fault path is already covered because filemap_fault() itself grabs invalidate_lock shared on instantiation/read paths; only page_mkwrite was bypassing it in this driver.

Affected packages

Ecosystem Package Introduced Fixed