---
id: CVE-2026-97595
title: |-
  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->…
summary: |-
  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->…
severity: high
cvss: 7.5
cvssVector: 'CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H'
vendor: Linux
product: Linux
affected:
  - >-
    Linux >= 57588c71177f0bfc08509c2c3a9bfe32850c0786 <
    4740ef0518c5e3bf31ebfb2288a6ac3b462ead06
  - >-
    Linux >= 57588c71177f0bfc08509c2c3a9bfe32850c0786 <
    07f0214018d7241e3610c1be984c8abfce16c099
  - >-
    Linux >= 57588c71177f0bfc08509c2c3a9bfe32850c0786 <
    3d1fde35f95d7f02a7dc473c51d81e8d9e992cfc
  - >-
    Linux >= 57588c71177f0bfc08509c2c3a9bfe32850c0786 <
    2f37fba846c9fdff5fc15b6d93656057ccd13031
  - Linux 6.3
published: '2026-09-25'
updated: '2026-09-25'
sourceUpdated: '2026-09-25T15:18:00.797'
source: NVD
sourceUrl: 'https://nvd.nist.gov/vuln/detail/CVE-2026-97595'
references:
  - url: 'https://git.kernel.org/stable/c/07f0214018d7241e3610c1be984c8abfce16c099'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://git.kernel.org/stable/c/2f37fba846c9fdff5fc15b6d93656057ccd13031'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://git.kernel.org/stable/c/3d1fde35f95d7f02a7dc473c51d81e8d9e992cfc'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://git.kernel.org/stable/c/4740ef0518c5e3bf31ebfb2288a6ac3b462ead06'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
tags:
  - nvd
  - cve.org
ingestedAt: '2026-09-25T11:06:38.903Z'
---

## Overview

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.

## Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.