CVE-2026-92487: exfat: fix valid_size extension over a shared writable mapping
In the Linux kernel, the following vulnerability has been resolved:
exfat: fix validsize extension over a shared writable mapping
When a shared writable mapping has its validsize extended by a buffered write or a page fault, exfat zeroes the page-cache gap below the new validsize. A store through the mapping can race with this zeroing and be overwritten.
Fix this by zeroing the gap lazily. Drop ->mappages so that every first write fault goes through exfatpagemkwrite(), which advances validsize to cover the faulting page. With fault-around enabled, a store could install a writable PTE, skip ->pagemkwrite(), and land past validsize without advancing it. Extending validsize 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 validsize covers it.
Event History
Frequently Asked Questions
Which workloads are exposed to this race?
The affected scenario requires an exFAT file accessed through a shared writable mapping, with valid_size being extended by either a buffered write or a page fault. A store through that mapping must race with zeroing of the page-cache gap below the newly extended valid_size.
What changes reduce the race after the fix?
First write faults are routed through exfat_page_mkwrite() so valid_size advances to cover the faulting page. On buffered writes, the gap is unmapped before zeroing while the invalidate lock is held, forcing racing stores to fault again and complete only after zeroing and valid_size extension.