CVE-2026-92487

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.

CVSS

No CVSS.

References

Link	Resource
https://git.kernel.org/stable/c/1135704ed22f54873eb0498a232611d9eca30dd4
https://git.kernel.org/stable/c/24f20986b253c3e4eb13ebe3c2007d1d352408a6

Configurations

No configuration.

History

17 Sep 2026, 17:17

Type	Values Removed	Values Added
New CVE

Information

Published : 2026-09-17 17:17

Updated : 2026-09-17 17:17

NVD link : CVE-2026-92487

Mitre link : CVE-2026-92487

CVE.ORG link : CVE-2026-92487

JSON object : View

Products Affected

No product.

CWE

No CWE.

{"id": "CVE-2026-92487", "cveTags": [], "metrics": {}, "affected": [{"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "affectedData": [{"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "vendor": "Linux", "product": "Linux", "versions": [{"status": "affected", "version": "82a81a7352bcf5f2756ac33d47ee0582737e9a85", "lessThan": "24f20986b253c3e4eb13ebe3c2007d1d352408a6", "versionType": "git"}, {"status": "affected", "version": "82a81a7352bcf5f2756ac33d47ee0582737e9a85", "lessThan": "1135704ed22f54873eb0498a232611d9eca30dd4", "versionType": "git"}], "programFiles": ["fs/exfat/exfat_fs.h", "fs/exfat/file.c", "fs/exfat/iomap.c"], "defaultStatus": "unaffected"}, {"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "vendor": "Linux", "product": "Linux", "versions": [{"status": "affected", "version": "7.2"}, {"status": "unaffected", "version": "0", "lessThan": "7.2", "versionType": "semver"}, {"status": "unaffected", "version": "7.2.6", "versionType": "semver", "lessThanOrEqual": "7.2.*"}, {"status": "unaffected", "version": "7.3-rc1", "versionType": "original_commit_for_fix", "lessThanOrEqual": "*"}], "programFiles": ["fs/exfat/exfat_fs.h", "fs/exfat/file.c", "fs/exfat/iomap.c"], "defaultStatus": "affected"}]}], "published": "2026-09-17T17:17:50.800", "references": [{"url": "https://git.kernel.org/stable/c/1135704ed22f54873eb0498a232611d9eca30dd4", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/24f20986b253c3e4eb13ebe3c2007d1d352408a6", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}], "vulnStatus": "Received", "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nexfat: fix valid_size extension over a shared writable mapping\n\nWhen a shared writable mapping has its valid_size extended by a buffered\nwrite or a page fault, exfat zeroes the page-cache gap below the new\nvalid_size. A store through the mapping can race with this zeroing and be\noverwritten.\n\nFix this by zeroing the gap lazily. Drop ->map_pages so that every first\nwrite fault goes through exfat_page_mkwrite(), which advances valid_size to\ncover the faulting page. With fault-around enabled, a store could install a\nwritable PTE, skip ->page_mkwrite(), and land past valid_size without\nadvancing it. Extending valid_size one faulting page at a time also leaves\nnever-written pages in a large mapping alone.\n\nThe gap is filled with block granularity, zeroing only the not-uptodate\nblocks and preserving blocks that may hold data stored through the mapping.\nOn the buffered-write path the invalidate lock is held and the gap is\nunmapped before zeroing, so a racing store re-faults and, under the inode\nlock, completes only after the gap has been zeroed and valid_size covers\nit."}], "lastModified": "2026-09-17T17:17:50.800", "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}