CVE-2026-64424

What it actually does

CVE-2026-64424 is a Linux kernel use-after-free flaw in the netpoll shutdown path. During netpoll cleanup, the kernel can free netpoll state while a pending transmit worker can still run and access that freed memory through the queued work item. The resolved fix changes the worker shutdown behavior so delayed work is fully disabled and synchronized before the associated netpoll data is freed. The most likely technical result is a kernel crash, memory corruption, or denial of service when netpoll is being disabled or torn down while transmit work is pending. Practical remote code execution is not indicated by the available details, and current exploit maturity is listed as none.

Why it matters to the business

Systems using affected Linux kernels with netpoll-dependent functionality, such as network console or low-level network polling paths, may experience kernel instability or crashes during shutdown, reconfiguration, driver teardown, or netpoll disablement. In production, this can translate into service interruption, node reboot, degraded availability, failed maintenance operations, or loss of diagnostic network logging during incidents. The current EPSS score is low and the issue is not listed in CISA KEV, so broad active exploitation is not currently indicated, but kernel-level denial-of-service risk still warrants remediation through normal kernel update processes.

How an attack unfolds

An attacker would need to cause or align with a condition where netpoll is active and then is shut down or cleaned up while transmit work remains pending. During cleanup, the kernel clears the netpoll reference and schedules RCU cleanup, but the delayed transmit work may not be synchronously stopped before the netpoll information structure is freed. If the worker later executes, it can access freed memory and trigger memory corruption or a kernel crash. In realistic scenarios, exploitation is more likely to require local privileges, administrative control over networking or netconsole configuration, or a workload that can repeatedly trigger netpoll teardown races. No public exploit or active exploitation is indicated by the provided data.

How to fix it

Apply the Linux kernel update that contains the netpoll shutdown fix for CVE-2026-64424 from the relevant distribution, appliance, cloud image, or kernel vendor. Because no exact affected products or fixed versions were provided, use vendor advisories and package changelogs to identify the corrected kernel build. Reboot systems after kernel update where required so the fixed kernel is actually running. If immediate patching is not possible, reduce exposure by disabling unnecessary netpoll-dependent features such as netconsole where operationally feasible, avoid nonessential network device teardown/reconfiguration on vulnerable kernels, and restrict administrative access capable of changing kernel networking configuration.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel version, not only the installed package version, includes the vendor fix for the netpoll use-after-free. Check distribution advisories, kernel package changelogs, or source commits referencing the netpoll cleanup change that uses synchronized delayed-work disabling. After reboot, validate with commands appropriate to the platform, such as checking the active kernel release and package metadata. For exposure assessment, inventory systems using netpoll or netconsole and prioritize those for update. In test environments, enabling kernel sanitizers such as KASAN can help confirm the race no longer produces slab-use-after-free reports during netpoll shutdown or network device teardown testing.

Typical attack path

1. Identify a Linux system running an affected kernel with netpoll-related functionality enabled or reachable through configuration paths such as netconsole or network polling.
2. Obtain the ability to influence network device teardown, netpoll disablement, module unload, interface reconfiguration, or shutdown paths.
3. Create timing pressure by generating or leaving pending netpoll transmit work while triggering netpoll cleanup.
4. Race the cleanup path so netpoll state is freed before the pending transmit worker fully stops.
5. Cause the worker to access freed kernel memory, resulting in kernel memory corruption, a crash, or denial of service.

How to detect it

To determine whether this flaw may have been triggered, review kernel logs, crash dumps, panic records, hypervisor reset events, and endpoint telemetry for evidence of kernel use-after-free crashes involving netpoll cleanup, delayed work, queue_process, skb_dequeue, or _raw_spin_lock_irqsave. Useful sources include dmesg output, journalctl kernel logs, /var/log/kern.log, /var/log/messages, kdump/vmcore analysis, pstore/ramoops records, and infrastructure monitoring that records unexpected reboots or node panics. Look for crashes occurring during network interface shutdown, driver unload, netconsole disablement, host shutdown, or maintenance activities. There are no known attacker-specific indicators, threat actors, network payloads, files, registry keys, or process names associated with exploitation based on the supplied information; detection should focus on kernel crash artifacts and repeated race-condition symptoms.

• BUG: KASAN: slab-use-after-free in _raw_spin_lock_irqsave
• slab-use-after-free in _raw_spin_lock_irqsave
• Workqueue: events queue_process
• skb_dequeue+0x1e/0xb0
• queue_process+0x2c/0x600
• __netpoll_cleanup
• rcu_cleanup_netpoll_info
• __netpoll_setup
• netpoll_setup
• enabled_store
• cancel_delayed_work
• disable_delayed_work_sync
• dev->npinfo

What your security team should do

• Track vendor kernel advisories for CVE-2026-64424 and schedule updates through the standard kernel patch cycle, with priority for systems using netconsole, crash diagnostics over network, or low-level network polling features.
• Prioritize availability-sensitive systems, clustered nodes, appliances, virtualization hosts, and systems where an unexpected kernel panic would cause material operational impact.
• Verify that patched systems have been rebooted into the corrected kernel; installed-but-not-running kernel packages do not mitigate this issue.
• Limit administrative access to network reconfiguration, module unload, and netpoll/netconsole configuration paths on unpatched systems.
• Monitor kernel logs and crash telemetry for use-after-free, workqueue, netpoll, and queue_process crash signatures until updates are complete.
• Because there is no current KEV listing, no ransomware association, low EPSS, and no known exploit maturity, treat this as a stability and hardening priority rather than an emergency internet-wide exploitation event unless vendor or threat intelligence changes.