PT-2026-135530

CVE-2026-99241

·

Published

2026-11-02

·

Updated

2026-11-02

Description by

Score
N/A
Not available

No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.

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.
Vendors
Affected products
Related identifiers
Found an issue in the description? Have something to add? Feel free to write us 👾