# CVE-2026-97595: mac802154: fix use-after-free of sdata via queued RX frames

> A use-after-free vulnerability in the Linux kernel mac802154 subsystem allows attackers to cause denial of service or potentially execute code via crafted MAC command frames.

- **Severity:** High 7.5 (`CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H`)
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Local or same network only
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 25 Sep 2026
- **Updated:** 19 Oct 2026
- **Also known as:** AZL-104334, BELL-CVE-2026-97595, DEBIAN-CVE-2026-97595, GHSA-jxcw-xwwv-r3hm, UBUNTU-CVE-2026-97595

## What is CVE-2026-97595?

CVE-2026-97595 is a high-severity use after free vulnerability in Linux, published on 25 Sep 2026. It can only be exploited from the same machine or local network, with no action from the victim.

### Official 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.

## Which versions are affected by CVE-2026-97595?


## How do I fix CVE-2026-97595?

Apply the vendor's patch.

## Is CVE-2026-97595 being exploited?

There is no known exploitation of CVE-2026-97595 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2026-97595 and fix it if it is affected.

What it is: CVE-2026-97595 is a high-severity use after free vulnerability in Linux, published on 25 Sep 2026. It can only be exploited from the same machine or local network, with no action from the victim.
Exploitation: There is no known exploitation of CVE-2026-97595 in the wild and no public exploit code.

Affected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page.

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2026-97595/ (Markdown: https://insights.sbomify.com/CVE-2026-97595/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2026-97595
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-97595
- OSV: https://osv.dev/vulnerability/CVE-2026-97595

---
From sbomify Insights: https://insights.sbomify.com/CVE-2026-97595/
Summaries are generated and may contain mistakes; the official description above is the record.