CVE-2026-97595: mac802154: fix use-after-free of sdata via queued RX frames
In the Linux kernel, the following vulnerability has been resolved:
mac802154: fix use-after-free of sdata via queued RX frames
The RX softirq producer ieee802154subifframe() queues received beacon and MAC-command frames onto local->rxbeaconlist / rxmaccmdlist and schedules a process-context worker, storing a raw macpkt->sdata (and skb->dev == sdata->dev) with neither a reference nor any locking:
- the lists have no lock: the softirq producer listaddtail()s while the macwq worker listdel()s, so sibling interfaces on the same phy corrupt the list;
- the workers dereference the interface after it may have been freed. mac802154rxmaccmdworker() touches macpkt->sdata directly, and mac802154rxbeaconworker() -> mac802154processbeacon() dereferences skb->dev (== sdata->dev). Removing an interface frees its sdata (netdevpriv) while a queued frame still points at it, so a later worker run is a use-after-free.
Reproduced under KASAN by flooding a victim interface with MAC command frames and removing it (the beacon path is the same class via skb->dev):
BUG: KASAN: slab-use-after-free in mac802154rxmaccmdworker+0x463/0x630 [mac802154] Read of size 4 at addr ffff888002f9ea18 by task kworker/u8:1/31 Workqueue: phy0-mac-cmds mac802154rxmaccmdworker [mac802154] Call Trace: mac802154rxmaccmdworker+0x463/0x630 [mac802154] processonework+0x611/0xe80 workerthread+0x52e/0xdc0 kthread+0x30c/0x630 retfromfork+0x2fd/0x3e0
Fix both lists together:
- add local->rxlock and take it around every list access: the softirq producer (plain spinlock, softirq context) and the workers and flush (spinlockbh, process context);
- pin the interface for the lifetime of a queued frame with netdevhold()/netdevput(), so the worker can safely dereference sdata / skb->dev even while the interface is being removed;
- dequeue under the lock at the head and loop-drain the whole list in the workers (they previously processed one frame per run and relied on a later enqueue to drain the rest);
- drop not-yet-started frames of an interface before it is unregistered, from ieee802154ifremove() (after the RCU grace period) and from the ieee802154removeinterfaces() loop -- the latter is the whole-phy teardown path, which does not go through ieee802154ifremove().
An in-flight worker that already dequeued a frame keeps its own netdev reference; unregisternetdevice() then waits it out in netdevruntodo(), which runs at rtnlunlock() (rtnl released) and after the interface has been closed, so it does not pin rtnl. A worker blocked in an association TX only delays that one interface's unregister (the usual "waiting for %s to become free"), it does not hold rtnl. netdevhold() is used for this reason instead of a cancelworksync() under rtnl, which would block on the worker's unbounded MLME TX wait via ieee802154syncqueue().
The mac-command worker additionally skips processing for a stopped interface (ieee802154sdatarunning()), avoiding a needless association response during teardown.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Protect both RX frame lists with a local->rx_lock: take the lock around every list access, dequeue at the head under the lock, and loop-drain the lists so the softirq producer and process-context workers cannot concurrently corrupt them.
- Compensating control
Ensure queued RX frames keep their interface alive with netdev_hold()/netdev_put(), and drop not-yet-started frames for an interface before unregistering it; this prevents workers from dereferencing freed sdata or skb->dev during teardown.
Event History
Frequently Asked Questions
Who is exposed to this issue?
Systems using the Linux kernel's mac802154 subsystem are exposed when they process received IEEE 802.15.4 beacon or MAC-command frames. The issue involves interfaces sharing the same PHY, where concurrent receive processing can also corrupt the queued-frame lists.
What conditions are needed to trigger the use-after-free?
Received beacon or MAC-command frames must be queued for worker processing, and the associated interface must then be removed before the worker runs. The reported reproduction floods a victim interface with MAC-command frames and removes it.
How can I tell whether a system has encountered this issue?
A triggered condition may produce a KASAN slab-use-after-free report identifying mac802154_rx_mac_cmd_worker. The described beacon-frame path can similarly dereference a freed interface through skb->dev.
What should be done if patching cannot happen immediately?
The provided information does not describe a workaround. Reducing exposure would require avoiding removal of mac802154 interfaces while received beacon or MAC-command frames may still be queued, but this is not presented as a complete mitigation.