CVE-2026-64216

What it actually does

This is a use-after-free flaw in the Linux kernel netfs code path. During cleanup of abandoned network filesystem read requests, netfs_unlock_abandoned_read_pages() and a related path in netfs_unlock_read_folio() can dereference a folio after ownership has reverted to the caller. If an attacker can trigger the vulnerable netfs read/write interaction, the kernel may access freed or repurposed memory, potentially causing kernel memory corruption, system crash, information disclosure, or privilege-impacting code execution depending on heap state and exploitability on the target kernel build.

Why it matters to the business

Successful exploitation can compromise the confidentiality, integrity, and availability of Linux systems that use affected kernel versions and vulnerable netfs functionality. Operationally, the most likely visible impact is instability, kernel panic, or unplanned reboot; in a worst case, exploitation could lead to full host compromise. Although the CVSS rating is critical, EPSS is currently low and there is no known CISA KEV listing or ransomware association, so organizations should prioritize patching exposed or netfs-dependent Linux workloads while continuing normal emergency monitoring.

How an attack unfolds

An attacker first identifies a Linux system running an affected kernel with reachable or usable network filesystem functionality that exercises the netfs read request path. The attacker then causes a specific timing and state transition around abandoned read pages, where NETFS_RREQ_IN_PROGRESS is cleared and a folio that should no longer be dereferenced is still accessed by the cleanup routine. By repeatedly shaping read/write behavior and memory pressure, the attacker may attempt to turn the stale folio access into a controlled use-after-free condition. Depending on kernel configuration, allocator behavior, mitigations, and the reachable attack surface, exploitation may result in a denial of service through a kernel oops or panic, or potentially in memory corruption leading to broader system compromise.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the netfs use-after-free in netfs_unlock_abandoned_read_pages() and netfs_unlock_read_folio(). Because no product-specific fixed versions were provided, use the security advisories from the relevant Linux distribution, appliance vendor, cloud image provider, or kernel maintainer and upgrade to the first kernel release that backports this fix. Reboot into the updated kernel and remove or decommission superseded vulnerable kernels where operationally feasible. As interim risk reduction, limit exposure of network filesystem services, disable unused netfs-dependent functionality, restrict access to systems using network filesystems, and increase monitoring for kernel crashes or memory-corruption symptoms. Kernel live patching may be acceptable only if the vendor explicitly states that this issue is covered by the live patch.

How to confirm the fix worked

Confirm the running kernel version, not just the installed package version, after remediation. Validate that the active kernel includes the vendor advisory fix or the upstream patch changing the vulnerable netfs logic to compare the stored folio pointer rather than dereferencing by index after ownership changes. On Linux, compare `uname -r` with the vendor-fixed kernel package, verify package manager history for the applied security update, and ensure the system has rebooted or live-patched successfully. Where source or symbol validation is available, confirm the updated netfs implementation no longer performs the vulnerable dereference pattern in netfs_unlock_abandoned_read_pages() or netfs_unlock_read_folio(). Also review kernel logs after patching for absence of recurring oops, panic, KASAN, or netfs stack traces under representative network filesystem workload tests.

Typical attack path

1. Identify Linux systems running affected kernel builds with netfs-related functionality enabled or reachable through network filesystem workloads.
2. Trigger network filesystem read/write operations that enter the vulnerable netfs read request cleanup path.
3. Cause or wait for an abandoned read request state where folio ownership changes after NETFS_RREQ_IN_PROGRESS is cleared.
4. Induce the vulnerable function to dereference the stale folio reference.
5. Leverage the resulting use-after-free for kernel crash, memory disclosure, memory corruption, or potential code execution depending on exploit reliability and target hardening.

How to detect it

There is no reliable network signature that uniquely proves exploitation of this kernel memory-safety issue. Detection should focus on host and kernel telemetry: collect journald, syslog, dmesg, kernel ring buffer, crash dumps, kdump/vmcore artifacts, EDR process and reboot telemetry, and storage or network filesystem service logs. Look for kernel oops or panic events with stack traces involving netfs_unlock_abandoned_read_pages(), netfs_unlock_read_folio(), netfs read request cleanup, folio unlock operations, or KASAN/KFENCE reports showing use-after-free in fs/netfs code. Correlate these events with bursts of network filesystem reads/writes, abnormal client access patterns, repeated service restarts, unexpected reboots, or memory-pressure events. For forensic review, preserve vmcore dumps and kernel logs before reboot cleanup, then compare the running kernel against vendor-fixed versions to determine whether crashes occurred on vulnerable builds. Absence of these artifacts does not rule out exploitation, especially if kernel crash dumps are disabled or logs were lost after reboot.

• netfs_unlock_abandoned_read_pages
• netfs_unlock_read_folio
• NETFS_RREQ_IN_PROGRESS
• fs/netfs
• BUG: KASAN: use-after-free
• KASAN: use-after-free
• KFENCE: use-after-free
• kernel BUG at fs/netfs
• Oops:
• Kernel panic - not syncing
• general protection fault
• unable to handle kernel paging request
• netfs:
• folio

What your security team should do

• Inventory Linux systems running kernels that include netfs functionality, prioritizing servers using network filesystems or storage-heavy workloads.
• Track distribution and vendor advisories for this kernel issue and patch to the first fixed kernel available for each platform.
• Prioritize externally reachable, multi-tenant, storage gateway, file service, virtualization, and container host workloads because kernel compromise or crashes have broad blast radius.
• Confirm systems are actually booted into the fixed kernel after patch deployment.
• If immediate patching is not possible, reduce access to network filesystem services and disable unused netfs-dependent features where feasible.
• Monitor kernel logs, crash dumps, and EDR telemetry for use-after-free, KASAN, oops, panic, or stack traces referencing netfs_unlock_abandoned_read_pages() or netfs_unlock_read_folio().
• Because there is no KEV listing, no known ransomware association, and low current EPSS, treat this as high-severity patch management rather than confirmed active exploitation, while remaining alert for new exploit publication.