CVE-2026-64067: Linux Kernel Race Condition Vulnerability

CVE-2026-64067 Overview

CVE-2026-64067 is a Linux kernel vulnerability in the netfs network filesystem helper library. The flaw involves missing memory barriers when netfs_collect_read_results() and netfs_collect_write_results() access the stream->subrequests list without holding locks. Consumers read subreq->flags before a proper acquire barrier, while list producers omit a release barrier when publishing new entries. This creates a race condition where the NETFS_SREQ_IN_PROGRESS flag may not be observed as set before the subrequest pointer becomes visible to concurrent readers.

Critical Impact
A memory ordering race in the Linux kernel netfs collector allows concurrent CPUs to observe partially initialized subrequest state, potentially leading to kernel memory corruption or inconsistent I/O state on affected filesystems.

Affected Products

Linux kernel versions containing the netfs collector code prior to commit 293a4532c36f
Linux kernel versions prior to commit b5782e2d462c
Network filesystems built on the netfs helper library (including AFS, Ceph, 9p, and cifs/SMB in netfs mode)

Discovery Timeline

2026-07-19 - CVE-2026-64067 published to NVD
2026-07-20 - Last updated in NVD database

Technical Details for CVE-2026-64067

Vulnerability Analysis

The Linux kernel netfs library orchestrates asynchronous reads and writes for network filesystems by dividing I/O into subrequests attached to a per-stream list. The collector functions netfs_collect_read_results() and netfs_collect_write_results() walk stream->subrequests without acquiring the stream lock as an optimization for hot-path completion handling.

This lockless traversal is only safe when paired with matching memory barriers between producers and consumers. The original implementation lacked those barriers. Producers building the subrequest list did not issue a release barrier after initializing subreq->flags (including NETFS_SREQ_IN_PROGRESS), and consumers issued no acquire barrier after loading the subreq pointer from the list. On weakly ordered architectures such as arm64, a consumer CPU could observe the list pointer before observing the flag store, dereferencing a subrequest whose state has not yet been published.

Root Cause

The root cause is a memory ordering defect (race condition) in lockless list traversal. Without a release-store when appending and an acquire-load when reading the head, there is no happens-before relationship between subrequest initialization and its visibility to the collector. The result is a Time-of-Check Time-of-Use style hazard where the collector inspects subreq->flags on a not-yet-fully-initialized structure.

Attack Vector

The attack surface is reachable through any workload that drives concurrent I/O on a netfs-backed filesystem while collection runs on a different CPU. On network filesystems accessible to unprivileged users, a local attacker can generate the sustained parallel read/write patterns needed to widen the race window. The vulnerable code path executes in kernel context, so successful exploitation of the resulting state confusion affects kernel memory integrity.

No public proof-of-concept exploit or in-the-wild exploitation has been reported. The vulnerability is a concurrency defect rather than a directly weaponizable primitive, and reliable exploitation would require additional kernel-level techniques.

Detection Methods for CVE-2026-64067

Indicators of Compromise

Unexplained kernel oops or general protection fault messages referencing netfs_collect_read_results or netfs_collect_write_results in dmesg
KASAN or KCSAN reports flagging data races on stream->subrequests or subreq->flags
Filesystem I/O stalls, corruption, or EIO returns on AFS, Ceph, 9p, or cifs mounts under heavy concurrent load

Detection Strategies

Enable CONFIG_KCSAN on test kernels to surface the missing barriers as concrete data-race reports
Compare running kernel commit against upstream stable trees to confirm whether commits 293a4532c36f and b5782e2d462c are present
Correlate kernel crash telemetry with mounted network filesystem types to identify at-risk hosts

Monitoring Recommendations

Ship kernel ring buffer logs to a centralized SIEM and alert on stack traces containing netfs_collect_
Track kernel package versions across the fleet and flag hosts running unpatched kernels that mount netfs-backed shares
Monitor for abnormal reboot rates on file servers and clients using AFS, Ceph, 9p, or cifs

How to Mitigate CVE-2026-64067

Immediate Actions Required

Inventory all Linux hosts using netfs-backed filesystems (AFS, Ceph, 9p, cifs in netfs mode) and prioritize them for patching
Apply the vendor-provided kernel update containing commits 293a4532c36f and b5782e2d462c, then reboot
Restrict untrusted local user access on multi-tenant hosts running vulnerable kernels until patching completes

Patch Information

The upstream fix introduces two new helpers: list_add_tail_release() publishes a new list member using a release barrier, and list_first_entry_or_null_acquire() reads the head with an acquire barrier. The netfs code uses list_add_tail_release() when appending subrequests to ->subrequests and list_first_entry_or_null_acquire() when the collector first walks the list. Fixes are available in the Kernel Git Commit 293a45 and Kernel Git Commit b5782e2.

Workarounds

Unmount or avoid mounting network filesystems that rely on the netfs helper (AFS, Ceph, 9p, cifs) on unpatched hosts
Reduce concurrency on affected mounts by limiting parallel I/O workloads where operationally feasible
Where supported, switch cifs mounts back to the non-netfs code path until the kernel is updated

bash

# Verify the running kernel and confirm the patch is applied
uname -r
git -C /usr/src/linux log --oneline | grep -E '293a4532c36f|b5782e2d462c'

# Identify hosts with netfs-backed mounts
mount | grep -E 'type (afs|ceph|9p|cifs) '