CVE-2026-64067

What it actually does

This is a Linux kernel race condition in the netfs subsystem caused by missing memory-ordering barriers when locklessly accessing stream subrequest lists and subrequest flags. Under concurrent network filesystem read or write completion paths, one CPU may observe a subrequest pointer before the associated state is fully initialized or may observe stale flag values such as NETFS_SREQ_IN_PROGRESS. Depending on timing and kernel build/runtime conditions, this can lead to incorrect I/O completion handling, data corruption, kernel crashes, or potentially more severe kernel memory-safety consequences. Because the vulnerable logic is in kernel space, successful exploitation can affect confidentiality, integrity, and availability of the host.

Why it matters to the business

Systems that run a vulnerable Linux kernel and use netfs-backed functionality may be exposed to host instability, corrupted network filesystem I/O, service outages, or compromise of the operating system kernel. Although this issue has a high CVSS score, it is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS at the time of assessment, and has no reported public exploit maturity, so urgency should be driven by whether affected systems use network filesystem features and whether they are exposed to untrusted remote filesystem peers or untrusted workloads that can trigger heavy netfs I/O.

How an attack unfolds

An attacker first needs a way to drive the vulnerable netfs read or write paths, typically by interacting with a system that performs network filesystem I/O or by controlling/positioning a remote filesystem endpoint used by the vulnerable host. The attacker then causes concurrent reads, writes, completions, cancellations, or error paths at high frequency to increase the chance that lockless list traversal observes a subrequest before the expected flags and fields are visible across CPUs. If the race is won, the kernel may mishandle a subrequest, resulting in I/O state corruption, a kernel warning or panic, or potentially memory corruption in kernel context. Reliable exploitation would likely require precise timing, workload shaping, and kernel-version-specific behavior; no public exploit is indicated by the provided data.

How to fix it

Apply the Linux kernel update that includes the netfs memory-barrier fix introducing release semantics when adding subrequests and acquire semantics when reading the first subrequest from the list. Because no exact fixed package versions were provided, use vendor-specific kernel advisories and package repositories to identify the corrected kernel for each distribution, including backported fixes that may not change the upstream kernel version in an obvious way. Reboot into the patched kernel after installation; installing a kernel package alone is not sufficient if the host continues running the old kernel. Where immediate patching is not possible, reduce exposure by disabling or avoiding affected network filesystem functionality where operationally feasible, limiting access to untrusted remote filesystem servers, isolating workloads that can generate untrusted netfs I/O, and monitoring for kernel instability related to netfs paths.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, has been updated by checking the active kernel version and vendor advisory status after reboot. Validate whether netfs support is present with kernel configuration and filesystem checks such as reviewing /boot/config-$(uname -r) for NETFS-related options and checking mounted filesystems that may use netfs-backed paths. Review distribution changelogs or source patches for references to list_add_tail_release(), list_first_entry_or_null_acquire(), netfs subrequest barriers, or fixes in fs/netfs. Exercise representative network filesystem read/write workloads after patching and verify there are no kernel warnings, oopses, hangs, or I/O corruption. Vulnerability scanners should be tuned to recognize vendor backports rather than relying only on upstream version numbers.

Typical attack path

1. Identify Linux systems running a vulnerable kernel with netfs support enabled or actively using network filesystem-backed I/O.
2. Gain a position to influence the vulnerable I/O path, such as controlling a remote filesystem service, interacting with an application that performs network filesystem reads/writes, or running an untrusted workload that can generate netfs activity.
3. Generate high-concurrency read/write operations and completion/error conditions to stress netfs subrequest handling.
4. Attempt to trigger the missing acquire/release ordering race so subrequest state is observed inconsistently by the kernel.
5. Leverage the resulting condition for denial of service through kernel crash, I/O corruption, or, if a reliable memory corruption primitive is developed, possible kernel-level compromise.

How to detect it

There are no unique network indicators or attacker artifacts specific to this vulnerability from the provided information. Detection should focus on signs that the vulnerable netfs paths were stressed or failed: kernel logs, system journal, crash dumps, kdump/vmcore analysis, hypervisor reset events, and filesystem/application logs showing abrupt I/O failures. Search for kernel oops, panic, KASAN, lockless list corruption, general protection faults, or stack traces involving netfs_collect_read_results(), netfs_collect_write_results(), stream subrequests, or fs/netfs code. Correlate any such events with bursts of network filesystem reads/writes, unusual remote filesystem server behavior, untrusted workload activity, or repeated crashes under similar I/O patterns. Absence of these artifacts does not prove non-exploitation because a successful kernel-level exploit may leave minimal evidence beyond instability or a reboot.

• netfs_collect_read_results
• netfs_collect_write_results
• NETFS_SREQ_IN_PROGRESS
• fs/netfs
• KASAN: use-after-free
• KASAN: slab-out-of-bounds
• kernel BUG at fs/netfs
• WARNING: CPU:
• Oops: 0000
• general protection fault
• list_del corruption
• list_add corruption
• kernel panic
• BUG: unable to handle kernel NULL pointer dereference
• BUG: unable to handle page fault
• netfs:

What your security team should do

• Prioritize patching Linux systems that use network filesystems, cache remote file data, host multi-tenant workloads, or interact with untrusted remote filesystem endpoints.
• Verify that patched kernels are actually running after maintenance windows by checking post-reboot runtime kernel versions.
• Inventory systems with netfs-related kernel support and active network filesystem mounts to focus remediation where exposure is realistic.
• Temporarily reduce or restrict use of untrusted network filesystem sources until patched, especially on high-availability or sensitive systems.
• Monitor kernel, systemd-journald, and crash dump logs for netfs-related warnings, kernel oopses, list corruption, KASAN reports, and unexplained panics.
• Because this is not currently KEV-listed and EPSS is low, treat it as important kernel hardening rather than an active mass-exploitation emergency unless local telemetry shows suspicious crashes or netfs instability.