> rx_mac_cmd_list has no locking. The RX softirq producer in
> ieee802154_subif_frame() list_add_tail()s while the mac_wq worker
> list_del()s, and the worker dereferences mac_pkt->sdata with no
> liveness check.
>
> Removing an interface (or the phy) thus frees its sdata while a queued
> packet still points at it, and a later worker run reads freed memory: a
> KASAN use-after-free, reproduced by flooding a victim interface with MAC
> command frames and deleting it. Meanwhile sibling interfaces on the same
> phy keep adding to the list, corrupting it.
>
> Add rx_mac_cmd_lock around every access -- producer, worker (which now
> dequeues under the lock and processes the packet after) and the new
> mac802154_flush_queued_mac_cmds(). Drain the queue before the sdata is
> freed: from ieee802154_if_remove() after the RCU grace period (filtered
> to that sdata) and from ieee802154_unregister_hw(). The drain precedes
> cancel_work_sync() so a run that already dequeued a matching packet is
> waited out while its sdata is still alive.
>
> Fixes: d021d218f6d9 ("mac802154: Handle received BEACON_REQ")
> Cc: [email protected]
> Signed-off-by: Ibrahim Hashimov <[email protected]>
> Assisted-by: AuditCode-AI:2026.07
> ---Looks fine to me, but honestly this is flirting with the edge of my human memory. Reviewed-by: Miquel Raynal <[email protected]>
