CVE-2026-64064: netfs: Fix netfs_invalidate_folio() to clear dirty bit if all changes gone
In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix netfs_invalidate_folio() to clear dirty bit if all changes gone
If a streaming write is made, this will leave the relevant modified folio
in a not-uptodate, but dirty state with a netfs_folio struct hung off of
folio->private indicating the dirty range. Subsequently truncating the
file such that the dirty data in the folio is removed, but the first part
of the folio theoretically remains will cause the netfs_folio struct to be
discarded... but will leave the dirty flag set.
If the folio is then read via mmap(), netfs_read_folio() will see that the
page is dirty and jump to netfs_read_gaps() to fill in the missing bits.
netfs_read_gaps(), however, expects there to be a netfs_folio struct
present and can oops because truncate removed it.
Fix this by calling folio_cancel_dirty() in netfs_invalidate_folio() in the
event that all the dirty data in the folio is erased (as nfs does).
Also add some tracepoints to log modifications to a dirty page.
This can be reproduced with something like:
dd if=/dev/zero of=/xfstest.test/foo bs=1M count=1
umount /xfstest.test
mount /xfstest.test
xfs_io -c "w 0xbbbf 0xf96c" \
-c "truncate 0xbbbf" \
-c "mmap -r 0xb000 0x11000" \
-c "mr 0xb000 0x11000" \
/xfstest.test/foo
with fscaching disabled (otherwise streaming writes are suppressed) and a
change to netfs_perform_write() to disallow streaming writes if the fd is
open O_RDWR:
if (//(file->f_mode & FMODE_READ) || <--- comment this out
netfs_is_cache_enabled(ctx)) {
It should be reproducible even without this change, but if prevents the
above trivial xfs_io command from reproducing it.
Note that the initial dd is important: the file must start out sufficiently
large that the zero-point logic doesn't just clear the gaps because it
knows there's nothing in the file to read yet. Unmounting and mounting is
needed to clear the pagecache (there are other ways to do that that may
also work).
This was initially reproduced with the generic/522 xfstest on some patches
that remove the FMODE_READ restriction.
Security readout for executives and security teams
Plain-English summary
CVE-2026-64064 is a Linux kernel netfs bug where a specific write, truncate, and memory-mapped read sequence can leave stale dirty-page state and trigger a kernel oops. The public record does not show active exploitation or a CVSS score.
Executive priority
Treat as a patch-cycle kernel availability risk, not an emergency internet-facing compromise based on current evidence. Prioritize shared Linux hosts, multi-tenant workloads, and systems using netfs-backed storage.
Technical view
The flaw is in netfs_invalidate_folio(). After streaming writes, truncation can discard the netfs_folio private state while leaving the folio dirty. A later mmap read may route into netfs_read_gaps(), which expects that state and can oops. The fix clears the dirty bit when all dirty data is invalidated.
Likely exposure
Exposure is most likely on Linux systems running affected kernel versions with netfs paths where users or workloads can perform streaming writes, truncate files, and mmap-read the same file. Exact distribution impact requires vendor backport checks.
Exploitation context
The source includes a local reproduction scenario, but no evidence of public weaponization or CISA KEV listing. Impact appears availability-oriented from a kernel oops; broader confidentiality or privilege impacts are not established in the provided sources.
Researcher notes
The affected-version data in the bundle is sparse and partly commit-oriented. The reliable technical anchor is the upstream stable fix: netfs_invalidate_folio() now calls folio_cancel_dirty() when invalidation removes all dirty data.
Mitigation direction
Apply Linux kernel updates containing the referenced stable fixes.
Check distribution advisories for backported patches and affected package versions.
Prioritize systems allowing untrusted local users or workloads on netfs-backed files.
If patching is delayed, restrict untrusted access to affected netfs workflows.
Validation and detection
Inventory running kernel versions across Linux fleets.
Confirm whether vendor kernels include the referenced stable commits or equivalent backports.
Review use of netfs-backed filesystems and mmap-heavy workloads.
Monitor kernel logs for oops events involving netfs_read_folio or netfs_read_gaps.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-64064 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
5Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Jul 19, 2026, 15:39 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.