← All Advisories

CVE-2026-97595

Last refreshed2026-10-03

Status: UPDATED  |  Advisory ID: CVE-2026-97595

Key Details

CVECVE-2026-97595
CVSS Score / Version7.5 (High) / CVSS v3.1
Updated2026-09-25
CVSS VectorCVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS Proseattack vector is adjacent; attack complexity is high; privileges required is none; user interaction is none; scope is unchanged; confidentiality impact is high; integrity impact is high; availability impact is high.
Affected productsLinux Linux

Affected Products, Subsystems & Sectors

VendorProductAffected VersionsPatch Status
LinuxLinux
SubsystemsGeneral OT
SectorsMultiple

What to Know

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. (NVD)

What to Do

Monitor Linux's web page for any future patch releases.

References

SourceReference
NVDhttps://nvd.nist.gov/vuln/detail/CVE-2026-97595
CVEhttps://www.cve.org/CVERecord?id=CVE-2026-97595