CVE-2026-64068

What it actually does

This is a Linux kernel race condition in the netfs subsystem. The vulnerable retry paths, netfs_retry_read_subrequests() and netfs_retry_write_stream(), add additional subrequests to a stream without holding the required lock. Under concurrent retry activity, the shared subrequest list can be modified unsafely, potentially corrupting kernel data structures. Depending on timing and kernel configuration, exploitation may lead to kernel memory corruption, denial of service through a kernel crash or hang, and potentially broader compromise of confidentiality and integrity if an attacker can shape the race reliably.

Why it matters to the business

Successful exploitation can disrupt systems that rely on affected Linux kernels, especially servers or appliances using network-backed filesystems or netfs-backed I/O paths. A crash or kernel hang can take workloads offline, interrupt file access, and cause service outages. Although the CVSS score is critical, the currently reported EPSS is low, the issue is not listed in CISA KEV, it is not known to be used in ransomware campaigns, and no public exploit maturity is reported, so prioritization should be based on exposure to netfs/network filesystem functionality and standard kernel patch cadence.

How an attack unfolds

An attacker would need to cause vulnerable netfs retry logic to execute while concurrent read or write subrequest handling is occurring. In a realistic scenario, the attacker first targets a system using a vulnerable Linux kernel and a netfs-backed filesystem or service path. They then induce I/O failures, delays, partial reads or writes, or retry-heavy conditions so that netfs_retry_read_subrequests() or netfs_retry_write_stream() attempts to add new subrequests. By racing multiple retry operations, the attacker tries to trigger unsynchronized modification of stream->subrequests. If the race is won, the kernel may corrupt internal request-tracking state, leading to a crash, filesystem I/O instability, or potentially exploitable memory corruption. There are no named threat actors or known exploitation campaigns reported for this issue in the provided data.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for the netfs locking issue in netfs_retry_read_subrequests() and netfs_retry_write_stream(). Because no exact fixed package versions were provided, use the fixed kernel packages from the relevant Linux distribution, appliance vendor, cloud image provider, or kernel stable branch. Prioritize systems using network-backed filesystems or netfs-dependent features. If immediate patching is not possible, reduce exposure by disabling or limiting use of affected netfs-backed filesystem paths where operationally feasible, restricting access to services that can trigger heavy remote file I/O, reducing untrusted access to file operations, and monitoring for kernel instability. A reboot into the fixed kernel is typically required after applying kernel updates.

How to confirm the fix worked

Confirm that systems are running a kernel build containing the fix for the netfs retry locking change. Validate using vendor advisories, distribution package changelogs, kernel commit references, or build metadata rather than only package installation status. After patching, reboot and verify the active kernel with commands such as uname -a or vendor-specific inventory tooling. For exposure validation, identify systems using network-backed filesystems or netfs-dependent modules and review whether they were running vulnerable kernels before reboot. Functional validation should include normal and retry-heavy file I/O testing against affected filesystem paths while monitoring dmesg, journald, and kernel logs for netfs warnings, lockdep reports, kernel oops messages, or crashes.

Typical attack path

1. Identify a reachable Linux system running an affected kernel with netfs-backed read or write activity exposed through a service, network filesystem, or workload path.
2. Create conditions that force netfs read or write retries, such as high concurrency, interrupted I/O, delayed responses, partial operations, or backend instability.
3. Trigger multiple overlapping retry operations so new subrequests are added concurrently to the same stream.
4. Exploit the missing lock around stream->subrequests updates to corrupt kernel request state.
5. Leverage the resulting condition to crash the system, degrade filesystem availability, or, if further exploitation is possible, attempt kernel-level compromise.

How to detect it

Look for evidence of kernel instability and netfs-related fault paths rather than conventional application-layer compromise indicators. Relevant log sources include dmesg, /var/log/kern.log, /var/log/messages, systemd journal, crash dump infrastructure, kdump/vmcore records, hypervisor reset logs, EDR kernel telemetry, and filesystem service logs. Search for kernel oops, panic, soft lockup, general protection fault, list corruption, use-after-free, KASAN, UBSAN, or lockdep reports containing netfs_retry_read_subrequests(), netfs_retry_write_stream(), stream->subrequests, or other netfs stack frames. Correlate these events with bursts of network filesystem I/O, retry storms, backend timeouts, unexplained node reboots, or service outages. Absence of these artifacts does not prove exploitation did not occur, because a successful race may only produce a crash or transient corruption without durable forensic traces.

• netfs_retry_read_subrequests
• netfs_retry_write_stream
• stream->subrequests
• kernel BUG
• kernel panic
• Oops:
• general protection fault
• BUG: KASAN
• BUG: kernel NULL pointer dereference
• BUG: soft lockup
• WARNING: possible circular locking dependency detected
• list_add corruption
• list_del corruption
• netfs:

What your security team should do

• Prioritize patching Linux systems that use network-backed filesystems, file-serving workloads, or netfs-backed I/O paths.
• Track vendor kernel advisories and deploy the fixed kernel package as soon as available for each distribution or appliance platform.
• Reboot systems after patching and verify the active runtime kernel, not just the installed package version.
• Inventory systems using netfs-related functionality and give higher priority to internet-facing or multi-tenant workloads where untrusted users can influence file I/O.
• Review kernel logs from the period since publication for crashes, oops traces, lockdep warnings, or stack traces referencing netfs_retry_read_subrequests or netfs_retry_write_stream.
• If patching must be delayed, reduce untrusted access to workloads that can generate high-volume or retry-heavy network filesystem I/O.
• Because there is no KEV listing, no known ransomware usage, low EPSS, and no reported exploit maturity, handle as a critical kernel reliability and hardening update rather than as confirmed active exploitation unless local evidence indicates otherwise.