CVE-2026-93279 in Linux
Summary
by MITRE • 09/24/2026
In the Linux kernel, the following vulnerability has been resolved:
staging: octeon: add missing tasklet_kill in cvm_oct_tx_shutdown
The TX cleanup tasklet can be scheduled by the watchdog IRQ handler to execute cvm_oct_tx_do_cleanup. There can be a pending tasklet in the queue which might run after the cvm_oct_remove() frees net_device structures, causing a use-after-free in cvm_oct_tx_do_cleanup() as it iterates cvm_oct_device[] which is an array of netdevice pointers.
Add tasklet_kill() after free_irq() to ensure the tasklet is no longer scheduled or running before teardown proceeds.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/24/2026
The identified vulnerability resides within the Linux kernel staging driver for Octeon network interfaces, specifically affecting the cvm_oct_tx_shutdown routine. This issue manifests as a use-after-free condition arising from improper synchronization during device removal and shutdown sequences. The core of the problem lies in the lifecycle management of hardware interrupt handlers and their associated software tasklets. When the system initiates the teardown process for an Octeon network interface, it invokes cvm_oct_remove to free the net_device structures that represent the network interface to the operating system. However, if a TX cleanup tasklet is currently pending or actively executing in response to a watchdog IRQ handler, there exists a race condition where this tasklet may continue to execute after the underlying data structures have been deallocated.
The technical flaw stems from the asynchronous nature of interrupt handling and tasklet scheduling within the kernel. The watchdog IRQ handler has the capability to schedule cvm_oct_tx_do_cleanup as a tasklet. Tasklets are soft interrupts that run in process context but can be preempted or delayed, meaning they might not complete immediately after being scheduled. If the driver proceeds with freeing the net_device structures via free_irq and subsequent memory deallocation without explicitly stopping any pending tasklets, the kernel scheduler may still invoke cvm_oct_tx_do_cleanup at a later time. When this function executes, it attempts to iterate over the cvm_oct_device array, which contains pointers to the now-freed netdevice objects. Accessing these dangling pointers constitutes a classic use-after-free vulnerability, leading to memory corruption or arbitrary code execution depending on how the freed memory is reused by other kernel subsystems.
From an operational impact perspective, this vulnerability allows for potential denial of service and privilege escalation. A local attacker with access to network interfaces could trigger conditions that lead to the scheduling of the cleanup tasklet at a critical moment during device removal. By carefully timing actions or inducing high interrupt loads, an attacker might exploit the race window between freeing the net_device structures and the eventual execution of the deferred tasklet. This can result in kernel panics due to invalid memory accesses, effectively crashing the system. Furthermore, if the freed memory is reallocated for sensitive data structures, the use-after-free could potentially be leveraged to read or write arbitrary kernel memory, bypassing standard security controls such as KASLR and SMEP/SMAP protections that rely on preventing unauthorized access to kernel space from user context.
This vulnerability aligns with CWE-416, Use After Free, which describes the error of using a pointer after it has been freed, leading to undefined behavior. In terms of attack vectors, this scenario is consistent with ATT&CK technique T1059, Command and Scripting Interpreter, specifically when considering how kernel vulnerabilities are often chained with local privilege escalation exploits like Dirty Pipe or various heap spraying techniques that rely on precise memory state manipulation. The lack of proper synchronization between the hardware interrupt handler's scheduling mechanism and the driver's teardown logic represents a fundamental flaw in resource management within the staging driver codebase.
To mitigate this vulnerability, it is essential to ensure strict ordering during device removal operations. The primary remediation involves adding tasklet_kill() immediately after free_irq() in the cvm_oct_tx_shutdown function. This call ensures that any pending instances of the TX cleanup tasklet are flushed and prevented from being scheduled again before the driver proceeds with freeing resources. By explicitly killing the tasklet, the kernel guarantees that no deferred work will attempt to access the net_device structures once they have been released. Additionally, developers should review other interrupt handlers within the Octeon driver for similar patterns where softirqs or tasklets are scheduled without corresponding synchronization primitives during teardown. Implementing robust reference counting and ensuring that all asynchronous callbacks are properly cancelled before memory deallocation is critical for maintaining kernel stability and security in network drivers.