CVE-2026-64058

What it actually does

This is a local Linux kernel race condition in the netfs read path. netfs_read_folio() could inspect folio state while writeback was still in progress, meaning the dirty flag and folio->private metadata could be stale or already cleaned up by writeback cleanup logic. A local user able to exercise affected network filesystem-backed file operations may be able to trigger inconsistent kernel memory/object state, potentially causing kernel memory corruption, information disclosure, data corruption, denial of service, or privilege escalation depending on kernel configuration and reachable filesystem paths.

Why it matters to the business

Successful exploitation could let a low-privileged local user compromise the integrity and confidentiality of a Linux system or crash workloads running on it. The risk is highest on multi-user Linux systems, container hosts, developer workstations, shared compute platforms, and servers using netfs-backed filesystems. Although EPSS is currently very low and no known exploitation is reported, the CVSS impact is high because local kernel bugs can become full host compromises once reliable exploit techniques are developed.

How an attack unfolds

An attacker first needs local code execution as an unprivileged user on a vulnerable Linux kernel. They then repeatedly perform file I/O patterns that exercise the netfs folio read path while writeback is occurring, attempting to win the race where netfs_read_folio() observes folio state before writeback has completed. By forcing the kernel to act on stale dirty-state or folio-private metadata, the attacker may cause a crash or attempt to shape the race into memory corruption or object reuse that gives them elevated kernel capabilities. Exploitation is local rather than remote and is expected to be timing-sensitive, but the low attack complexity rating indicates the vulnerable condition is not considered difficult to reach once an attacker has local access.

How to fix it

Upgrade to a Linux kernel build from the relevant distribution or vendor that includes the upstream fix for netfs_read_folio() waiting for ongoing writeback before trusting folio state. Because no exact fixed package versions were provided, use the security advisory for the deployed distribution, cloud image, appliance, or embedded platform and install the first kernel version that references this CVE or the patch titled "netfs: Fix netfs_read_folio() to wait on writeback." Reboot into the patched kernel after installation; merely installing the package is not sufficient if the old kernel remains running. If immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads, reducing multi-tenant use on vulnerable hosts, disabling or avoiding affected netfs-backed filesystem use where operationally feasible, and strengthening container isolation because kernel vulnerabilities can cross container boundaries.

How to confirm the fix worked

Confirm the running kernel, not just the installed kernel package, is updated to a vendor-fixed build. Validate with commands such as `uname -r`, distribution package queries, and vendor advisory mapping for this CVE. Where source or backport information is available, confirm the kernel contains the netfs change that makes netfs_read_folio() wait for writeback completion before inspecting folio dirty/private state. After reboot, verify no hosts continue booting into the vulnerable kernel. For exposure checks, inventory Linux systems using netfs-related filesystems or caching paths and prioritize those with local users, container workloads, or shared compute use.

Typical attack path

1. Obtain local unprivileged access to a Linux system running an affected kernel.
2. Identify or create file activity that uses the affected netfs-backed read and writeback paths.
3. Generate concurrent reads, writes, cache pressure, and writeback activity to trigger the race in folio state handling.
4. Cause the kernel to operate on stale or cleaned-up folio-private metadata.
5. Use the resulting kernel fault for denial of service, or, with a reliable exploit, attempt privilege escalation or sensitive memory exposure.
6. Maintain or expand access if root/kernel-level control is achieved.

How to detect it

There are no known public exploitation indicators or network signatures for this issue, and exploitation would be local. Review kernel logs, audit logs, EDR telemetry, and crash dumps for signs of repeated kernel faults or memory-safety warnings around netfs, folio handling, read_folio, or writeback. Useful sources include `/var/log/kern.log`, `/var/log/messages`, `journalctl -k`, auditd process execution logs, eBPF/EDR file I/O telemetry, kernel crash dumps, and KASAN/KCSAN reports on debug kernels. Look for suspicious local users or containers generating high-volume concurrent file reads/writes against netfs-backed paths immediately before a kernel oops, panic, hung task, or memory corruption report. Because benign kernel bugs can produce similar artifacts, correlate crash timing with local process activity, recent account access, container activity, and repeated attempts from the same user or workload.

• netfs_read_folio
• fs/netfs/
• folio->private
• KASAN: use-after-free
• KASAN: slab-use-after-free
• BUG: kernel NULL pointer dereference
• BUG: unable to handle page fault
• kernel BUG at fs/netfs
• Oops:
• general protection fault
• kernel panic
• hung task
• writeback
• read_folio

What your security team should do

• Prioritize patching shared Linux hosts, container hosts, CI/CD runners, bastion systems, research/HPC nodes, and any systems where untrusted users or workloads can execute code.
• Track vendor advisories for exact fixed kernel package versions and ensure systems are rebooted into the fixed kernel.
• Use endpoint and configuration management tooling to identify vulnerable running kernel versions across fleets.
• Temporarily restrict local access and untrusted workload execution on systems that cannot be patched quickly.
• Review kernel logs for crashes, KASAN findings, or oops messages involving netfs, folios, read_folio, or writeback activity.
• Treat suspicious kernel crashes on vulnerable systems as possible exploitation attempts, especially when preceded by high-volume local file I/O from untrusted accounts or containers.
• Monitor exploit-development channels because local kernel race conditions can move from no public exploit to practical privilege-escalation code quickly.