exfat: fix valid_size extension over a shared writable mapping

Summary

In the Linux kernel, the following vulnerability has been resolved: exfat: fix valid_size extension over a shared writable mapping When a shared writable mapping has its valid_size extended by a buffered write or a page fault, exfat zeroes the page-cache gap below the new valid_size. A store through the mapping can race with this zeroing and be overwritten. Fix this by zeroing the gap lazily. Drop ->map_pages so that every first write fault goes through exfat_page_mkwrite(), which advances valid_size to cover the faulting page. With fault-around enabled, a store could install a writable PTE, skip ->page_mkwrite(), and land past valid_size without advancing it. Extending valid_size one faulting page at a time also leaves never-written pages in a large mapping alone. The gap is filled with block granularity, zeroing only the not-uptodate blocks and preserving blocks that may hold data stored through the mapping. On the buffered-write path the invalidate lock is held and the gap is unmapped before zeroing, so a racing store re-faults and, under the inode lock, completes only after the gap has been zeroed and valid_size covers it.

Timeline

1. Sep 17, 2026, 4:10 PM UTCCVE published
2. Oct 19, 2026, 9:03 AM UTCRecord last updated

Affected versions

• Linux Linux

  From 82a81a7352bcf5f2756ac33d47ee0582737e9a85 · fixed in 24f20986b253c3e4eb13ebe3c2007d1d352408a6; From 82a81a7352bcf5f2756ac33d47ee0582737e9a85 · fixed in 1135704ed22f54873eb0498a232611d9eca30dd4

• Linux Linux

  7.2

• KernelLinux

  From 7.2.0 · fixed in 7.2.6

References 2