{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "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-\u003erx_beacon_list / rx_mac_cmd_list and schedules a process-context worker, storing a raw mac_pkt-\u003esdata (and skb-\u003edev == sdata-\u003edev) 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-\u003esdata directly, and    mac802154_rx_beacon_worker() -\u003e mac802154_process_beacon() dereferences    skb-\u003edev (== sdata-\u003edev). 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-\u003edev):    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-\u003erx_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-\u003edev 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.",
  "id": "DEBIAN-CVE-2026-97595",
  "modified": "2026-09-26T04:47:42.088428842Z",
  "published": "2026-09-25T11:17:10.770Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-97595"
    }
  ],
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "upstream": [
    "CVE-2026-97595"
  ]
}