https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Thu, 05 Nov 2026 23:04:52 +0000 https://db.gcve.eu/vuln/cve-2026-99241 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>ntfs: take invalidate_lock in ntfs_filemap_page_mkwrite()</p> <p>ntfs_filemap_page_mkwrite() calls iomap_page_mkwrite() without holding mapping-&gt;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.</p> <p>Per Documentation/filesystems/locking.rst, -&gt;page_mkwrite() must ensure there are no truncate/invalidate races, &#34;usually mapping-&gt;invalidate_lock is suitable for proper serialization&#34;. xfs takes its mmaplock (= the invalidate_lock rwsem) shared in exactly this path.</p> <p>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.</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>ntfs: take invalidate_lock in ntfs_filemap_page_mkwrite()</p> <p>ntfs_filemap_page_mkwrite() calls iomap_page_mkwrite() without holding mapping-&gt;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.</p> <p>Per Documentation/filesystems/locking.rst, -&gt;page_mkwrite() must ensure there are no truncate/invalidate races, &#34;usually mapping-&gt;invalidate_lock is suitable for proper serialization&#34;. xfs takes its mmaplock (= the invalidate_lock rwsem) shared in exactly this path.</p> <p>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.</p> https://db.gcve.eu/vuln/cve-2026-99241