CVE-2026-97600: ieee802154: cc2520: fix FIFOP work use-after-free
In the Linux kernel, the following vulnerability has been resolved:
ieee802154: cc2520: fix FIFOP work use-after-free
The FIFOP interrupt handler queues cc2520fifopirqwork. On removal, cc2520remove() only flushes the work. The devm-managed FIFOP IRQ remains active until after ->remove() returns and can queue the work again after that flush, allowing it to run after the private data is released.
Disable the work with disableworksync() instead of flushing it, so the handler can no longer queue it once removal begins. Destroy the buffer mutex last, since the worker and the stop callback invoked through ieee802154unregisterhw() both take it.
Found by an in-house static analysis tool.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
In cc2520_remove(), disable the FIFOP IRQ work with disable_work_sync() instead of only flushing it, so the IRQ handler can no longer queue cc2520_fifop_irqwork during removal.
Linux kernel ieee802154 cc2520 driver FIFOP IRQ work shutdown = disable_work_sync()
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel CC2520 IEEE 802.15.4 driver are exposed during removal of the associated device or driver. The issue depends on the FIFOP interrupt being able to queue work while teardown is in progress.
What condition is required to trigger the use-after-free?
The CC2520 device removal path must begin, and the FIFOP interrupt must queue cc2520_fifop_irqwork after the removal code has flushed the work but before the devm-managed FIFOP IRQ is released. That queued worker can then run after its private data has been freed.
What is the relevant mitigation if the fix cannot be applied immediately?
The provided information identifies the vulnerable window as device or driver removal while the FIFOP IRQ remains active. Avoiding removal or teardown of affected CC2520 hardware prevents entering that specific race window.
How does the fix prevent the race?
The fix replaces flushing the queued work with disable_work_sync(), preventing the interrupt handler from queuing the work once removal starts. It also keeps the buffer mutex alive until after the worker and unregister stop callback can no longer use it.