CVE-2026-93278 in Linux
Summary
by MITRE • 09/24/2026
In the Linux kernel, the following vulnerability has been resolved:
staging: octeon: add missing napi_disable in cvm_oct_rx_shutdown
cvm_oct_rx_shutdown calls free_irq and netif_napi_del without disabling the napi instance first. As the free_irq only waits for completion of hard interrupt handlers, the napi poll function could still be active. If cvm_oct_remove proceeds to free the plat structure (which holds the NAPI instances), the active poll function will access freed memory, resulting in a use-after-free crash.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/24/2026
The vulnerability identified within the Linux kernel staging driver for Octeon network interfaces represents a critical concurrency flaw rooted in improper resource management during device shutdown sequences. Specifically, the cvm_oct_rx_shutdown function fails to invoke napi_disable before proceeding with interrupt and NAPI instance cleanup operations. This oversight creates a race condition where the Network API poll mechanism remains active even as its underlying resources are being deallocated. The root cause lies in the sequence of operations performed by free_irq and netif_napi_del, which do not inherently synchronize with or halt ongoing softirq processing associated with the NAPI instance. Consequently, if the driver removal process continues to free the platform structure containing these NAPI instances while a poll function is still executing, it results in a use-after-free condition that can lead to kernel crashes and potential system instability.
From a technical perspective, this flaw exploits the asynchronous nature of interrupt handling within the Linux networking stack. When an interface receives packets, the hardware triggers a hard interrupt which schedules a softirq for processing via the NAPI poll function. The free_irq routine ensures that any currently executing hard interrupt handler completes before returning control to the caller. However, it does not guarantee that scheduled or running softirqs associated with NAPI have finished execution. By omitting napi_disable, the driver allows the kernel scheduler to continue invoking the poll callback on memory structures that are in the process of being freed by cvm_oct_remove. This mismatch between hardware interrupt synchronization and software polling lifecycle management is a classic concurrency error often seen in complex device drivers where multiple threads or contexts access shared data without proper locking or state transitions.
The operational impact of this vulnerability is severe, primarily manifesting as kernel panics due to use-after-free memory corruption. When the active poll function attempts to dereference pointers within the freed platform structure, it accesses invalid memory addresses, leading to immediate system crashes or unpredictable behavior depending on what data was overwritten in that memory region before deallocation. In worst-case scenarios, if an attacker can trigger network traffic patterns that keep the NAPI poll function busy during driver removal, they might exploit this race condition to achieve arbitrary code execution by overwriting critical kernel structures with controlled values. This aligns closely with CWE-416, which describes use-after-free vulnerabilities where a pointer is used after it has been freed, and also relates to CWE-362 regarding concurrent execution risks involving shared resources without proper synchronization mechanisms.
To mitigate this vulnerability, the primary remediation involves ensuring that all active processing contexts are halted before any memory associated with them is released. The fix requires inserting napi_disable calls immediately prior to invoking free_irq and netif_napi_del within the cvm_oct_rx_shutdown function. This ensures that no new poll cycles can be scheduled and allows existing ones to complete safely before the platform structure is destroyed. Additionally, developers should implement robust error handling paths in driver removal routines to guarantee cleanup consistency regardless of failure points during initialization or operation. Adhering to these practices aligns with secure coding standards for kernel modules and helps prevent similar concurrency-related flaws across other network drivers that manage NAPI instances alongside hardware interrupts.