https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Thu, 12 Nov 2026 07:21:46 +0000 https://db.gcve.eu/vuln/cve-2026-98496 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>net: airoha: npu: cancel wdt_work after releasing the WDT IRQ</p> <p>airoha_npu_remove() calls cancel_work_sync() on each core&#39;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()&#39;d and is freed in that same unwind, so the late work dereferences freed memory.</p> <p>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().</p> <p>This issue was identified during our ongoing static-analysis research while reviewing kernel code.</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>net: airoha: npu: cancel wdt_work after releasing the WDT IRQ</p> <p>airoha_npu_remove() calls cancel_work_sync() on each core&#39;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()&#39;d and is freed in that same unwind, so the late work dereferences freed memory.</p> <p>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().</p> <p>This issue was identified during our ongoing static-analysis research while reviewing kernel code.</p> https://db.gcve.eu/vuln/cve-2026-98496