Description

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 ieee802154_subif_frame() queues received beacon and MAC-command frames onto local->rx_beacon_list / rx_mac_cmd_list and schedules a process-context worker, storing a raw mac_pkt->sdata (and skb->dev == sdata->dev) with neither a reference nor any locking: - the lists have no lock: the softirq producer list_add_tail()s while the mac_wq worker list_del()s, so sibling interfaces on the same phy corrupt the list; - the workers dereference the interface after it may have been freed. mac802154_rx_mac_cmd_worker() touches mac_pkt->sdata directly, and mac802154_rx_beacon_worker() -> mac802154_process_beacon() dereferences skb->dev (== sdata->dev). Removing an interface frees its sdata (netdev_priv) 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 mac802154_rx_mac_cmd_worker+0x463/0x630 [mac802154] Read of size 4 at addr ffff888002f9ea18 by task kworker/u8:1/31 Workqueue: phy0-mac-cmds mac802154_rx_mac_cmd_worker [mac802154] Call Trace: mac802154_rx_mac_cmd_worker+0x463/0x630 [mac802154] process_one_work+0x611/0xe80 worker_thread+0x52e/0xdc0 kthread+0x30c/0x630 ret_from_fork+0x2fd/0x3e0 Fix both lists together: - add local->rx_lock and take it around every list access: the softirq producer (plain spin_lock, softirq context) and the workers and flush (spin_lock_bh, process context); - pin the interface for the lifetime of a queued frame with netdev_hold()/netdev_put(), 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 ieee802154_if_remove() (after the RCU grace period) and from the ieee802154_remove_interfaces() loop -- the latter is the whole-phy teardown path, which does not go through ieee802154_if_remove(). An in-flight worker that already dequeued a frame keeps its own netdev reference; unregister_netdevice() then waits it out in netdev_run_todo(), which runs at rtnl_unlock() (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. netdev_hold() is used for this reason instead of a cancel_work_sync() under rtnl, which would block on the worker's unbounded MLME TX wait via ieee802154_sync_queue(). The mac-command worker additionally skips processing for a stopped interface (ieee802154_sdata_running()), avoiding a needless association response during teardown.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-25T11:17:10.770Z",
  "pubdate": "2026-09-25T11:17:10.770Z",
  "executiveSummary": "A critical Use-After-Free (UAF) vulnerability exists within the Linux kernel's mac802154 subsystem, specifically affecting the handling of queued RX frames.\nThe vulnerability arises from improper lifecycle management of 'sdata' interface structures when processing beacon and MAC-command frames via softirqs and deferred workqueues.\nThe flaw allows for a race condition where a worker thread attempts to dereference an interface structure (sdata) that has already been deallocated during the interface removal process.\nThis vulnerability poses a significant risk to system stability and security, as it can lead to kernel memory corruption, arbitrary code execution, or denial-of-service through system crashes.\nAn attacker capable of triggering 802.15.4 frame reception on a target interface while simultaneously initiating an interface removal can exploit this race condition.\nThe issue is exacerbated by the lack of concurrency control (locking) for the RX frame lists and the absence of reference counting for the netdev structures associated with queued frames.",
  "technicalDetails": "The root cause of the vulnerability is a combination of missing synchronization and reference counting for mac802154 interface data structures (sdata) during asynchronous frame processing.\nWhen ieee802154_subif_frame() receives beacon or MAC-command frames, it enqueues them into global lists (rx_beacon_list or rx_mac_cmd_list) and schedules a workqueue (mac_wq) to process them in process context. The system failed to hold a reference to the associated net_device (via netdev_hold) or implement mandatory locking for list access.\nThe lack of locking leads to data corruption in the linked lists when multiple sibling interfaces on the same physical device perform concurrent additions or deletions. Furthermore, the absence of reference counting means that if an interface is removed while a frame is still queued in the workqueue, the subsequent worker thread (mac802154_rx_mac_cmd_worker or mac802154_process_beacon) will dereference a pointer to memory that has already been freed (slab-use-after-free).\nAttack flow: An attacker sends a flood of 802.15.4 MAC command frames to a target interface. While these frames are being queued for asynchronous processing, the attacker triggers an interface removal command (e.g., via netlink). The interface is unregistered, and its memory is released. When the workqueue subsequently executes, the worker routine attempts to access members of the now-freed sdata structure (such as dev or internal state), resulting in a kernel panic or KASAN-detected memory violation.\nThe vulnerability resides in the interaction between the softirq producer and the process-context worker. Because the worker relies on the existence of the sdata structure for the duration of the frame processing, the lack of a 'netdev_hold' call allows the interface's lifecycle to terminate independently of the queued work, violating the expected object lifetime guarantees.\nThe vulnerability is technically impactful because the kernel executes these workers with elevated privileges. Successful exploitation involves precisely timing the frame ingestion and the unregister_netdevice() path, making it a classic race condition exploitation scenario against kernel-mode memory management."
}