CVE-2026-97600: ieee802154: cc2520: fix FIFOP work use-after-free
ieee802154: cc2520: fix FIFOP work use-after-free
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Compensating control
In the Linux kernel ieee802154 cc2520 driver, call disable_work_sync() for cc2520_fifop_irqwork during removal instead of only flushing it, so the FIFOP interrupt handler cannot queue the work after removal begins.
- Compensating control
Destroy the cc2520 buffer mutex last, after the worker and the stop callback invoked through ieee802154_unregister_hw() have finished using it.
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.