CVE-2026-98496 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
net: airoha: npu: cancel wdt_work after releasing the WDT IRQ
airoha_npu_remove() calls cancel_work_sync() on each core's wdt_work, but the watchdog IRQ that queues it is requested with devm_request_irq() and is freed only after .remove() returns. airoha_npu_wdt_handler() can therefore schedule_work() again once the cancel has returned. struct airoha_npu, which contains the work, is devm_kzalloc()'d and is freed in that same unwind, so the late work dereferences freed memory.
Register the work with devm_work_autocancel() before devm_request_irq() and drop .remove(). Devres runs in reverse order, so the IRQ is freed before cancel_work_sync(), including when probe fails. A cancel left in .remove() cannot get that order. Initializing the work first also stops a pending watchdog interrupt from queuing an uninitialized work item. Probe currently calls INIT_WORK() only after devm_request_irq().
This issue was identified during our ongoing static-analysis research while reviewing kernel code.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/19/2026
The Linux kernel vulnerability in the Airoha NPU driver represents a classic use-after-free condition arising from improper resource management ordering within the device removal and initialization paths. The core technical flaw lies in the sequence of operations performed when unloading or failing to load the driver module. Specifically, the original implementation called cancel_work_sync on each core's watchdog timer work item during the remove function while relying on managed resources for both the memory allocation of the structure containing that work item and the request of the interrupt line. Because devm_request_irq ensures the interrupt handler remains active until after the remove callback completes, a race condition emerges where the hardware can trigger an interrupt even after cancel_work_sync has returned. This late-arriving interrupt causes the watchdog handler to schedule the work item again using schedule_work, effectively requeuing it for execution on memory that is in the process of being freed by the devm_kzalloc cleanup logic.
This race condition leads directly to a use-after-free vulnerability where kernel code attempts to dereference or execute functions within a struct airoha_npu instance that has already been deallocated from system memory. Such an event typically results in immediate kernel panic, denial of service through system crash, or potentially more severe outcomes if the freed memory region has been reallocated for other purposes and contains attacker-controlled data. The vulnerability is particularly insidious because it depends on timing conditions related to hardware interrupt latency and CPU scheduling, making it difficult to reproduce consistently without specific load patterns or stress testing during driver initialization failure scenarios.
The root cause of this issue can be mapped to CWE-416, Use After Free, as the system accesses memory after it has been freed due to incorrect ordering of resource release operations. Furthermore, from a defensive security perspective, this flaw aligns with ATT&CK technique T1059, Command and Scripting Interpreter, if an attacker could leverage the resulting instability or information leak to execute arbitrary code within the kernel context. The vulnerability was identified through static analysis research aimed at detecting improper resource management patterns in kernel subsystems, highlighting the importance of automated tooling in finding subtle concurrency bugs that manual review might miss due to their asynchronous nature.
To mitigate this vulnerability and prevent similar issues in future development, the recommended approach involves leveraging the Linux device resource management framework more effectively by registering work items with devm_work_autocancel before requesting interrupts via devm_request_irq. This ensures that when resources are released, they follow a reverse-order cleanup sequence where the interrupt is disabled and freed before any pending or scheduled work items are cancelled. By moving the initialization of the work item to occur prior to IRQ registration, developers also prevent scenarios where a watchdog interrupt might queue an uninitialized work structure during probe failures. Removing the explicit remove function in favor of relying on devres semantics guarantees that cleanup occurs safely regardless of whether the driver loads successfully or fails during initialization, thereby eliminating the window for race conditions between cancellation and hardware-triggered rescheduling.