Description
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.
Published: 2026-09-17
Score: n/a
EPSS: < 1% Very Low
KEV: No
Impact: Data Integrity Violation
Action: Update Kernel
AI Analysis

Impact

The vulnerability is a kernel‑level race condition affecting the exfat filesystem. When a file is mapped for shared writable access, the kernel expands the valid size of the mapping during a write or a fault and zeroes the gap in the page cache. A concurrent store through the mapping can race with this zeroing operation and be overwritten, potentially causing data loss or corruption. The flaw does not directly grant code execution but results in integrity violations of user files accessed via such mappings.

Affected Systems

All Linux kernels that include the exfat filesystem module are affected, regardless of distribution. The issue is present in any kernel build that uses the standard exfat driver, as identified by the generic Linux kernel CPE string.

Risk and Exploitability

The CVSS score is not provided, but the EPSS score is under 1 %, indicating a low likelihood of exploitation. The vulnerability is not listed in CISA’s KEV catalog. Attackers would need local user access to a system with exfat support and the ability to create a shared writable mapping. Given the low exploitation probability and absence of a known public exploit, the overall risk remains moderate but not negligible.

Generated by OpenCVE AI on September 19, 2026 at 05:43 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Apply the latest Linux kernel release that contains the exfat patch, ensuring the system is running a kernel version with the race condition fixed.
  • If an update is not immediately possible, avoid using shared writable mappings on exfat mounts; instead, use private mappings or disable write sharing as a temporary precaution.
  • Consider removing or disabling the exfat module from the kernel if exfat mounts are not required for the system’s operation.

Generated by OpenCVE AI on September 19, 2026 at 05:43 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Sat, 19 Sep 2026 06:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-362

Thu, 17 Sep 2026 16:30:00 +0000

Type Values Removed Values Added
Description 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.
Title exfat: fix valid_size extension over a shared writable mapping
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-09-17T16:10:02.317Z

Reserved: 2026-09-16T12:21:13.870Z

Link: CVE-2026-92487

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-17T17:17:50.800

Modified: 2026-09-17T17:17:50.800

Link: CVE-2026-92487

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-19T09:30:13Z

Weaknesses
  • CWE-362

    Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')