Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - mac802154：通过已排队的 RX 帧修复 sdata 的释放后使用 RX softirq 生产者 ieee802154_subif_frame（） 将接收到的信标和 MAC 命令帧排队到本地>rx_beacon_list/rx_mac_cmd_list，并计划进程上下文工作线程，从而存储原始 mac_pkt->sdata（和 skb->dev == sdata->dev），既没有引用也没有任何锁定：- 列表没有锁定： softirq 生产者list_add_tail（）s，而mac_wq工作线程list_del（）s，因此同一 phy 上的同级接口会损坏列表;- 工作线程在可能已经释放接口之后取消引用该接口。mac802154_rx_mac_cmd_worker（） 直接接触 mac_pkt->sdata，而 mac802154_rx_beacon_worker（） -> mac802154_process_beacon（） 取消引用 skb->dev （== sdata->dev）。删除接口会在排队的帧仍指向该接口时释放其 sdata （netdev_priv），因此后续的工作线程运行为释放后使用。在 KASAN 下，通过用 MAC 命令框架淹没受害者接口并将其删除而重现（信标路径通过 skb->dev 为相同类）：
    缺陷：KASAN：mac802154_rx_mac_cmd_worker+0x463/0x630 中的释放后使用 slab-use [mac802154] 任务 kworker/u8：1/31 在地址 ffff888002f9ea18 读取大小为 4 的工作队列：phy0-mac-cmds mac802154_rx_mac_cmd_worker [mac802154] 调用跟踪：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 同时修复两个列表： - 添加 local->rx_lock 并将其用于每个列表访问：softirq 生产者（普通spin_lock，softirq 上下文）和工作线程和刷新（spin_lock_bh，进程上下文）;- 通过 netdev_hold（）/netdev_put（） 针对排队帧的生命周期固定接口，以便工作线程即使在接口被删除时也可以安全地取消引用 sdata / skb->dev;- 在头部的锁下出列，并循环耗尽工作线程中的整个列表（他们之前每次运行处理一帧，并依靠稍后的排队来耗尽其余部分）;- 在接口未启动之前，从 ieee802154_if_remove（）（RCU 宽限期之后）和 ieee802154_remove_interfaces（） 循环中丢弃尚未启动的帧 -- 后者是不经过 ieee802154_if_remove（） 的 whole-phy 拆卸路径。已出列帧的正在传输的工作线程保留其自己的 netdev 引用;unregister_netdevice（） 然后在 netdev_run_todo（） 中等待它，后者在 rtnl_unlock（） （rtnl 已释放）时和接口关闭之后运行，因此它不会固定 rtnl。在关联 TX 中阻断的工作线程只会延迟一个接口的取消注册（通常等待 %s 释放），它不持有 rtnl。出于这个原因，使用 netdev_hold（） 而不是 rtnl 下的 cancel_work_sync（），后者会通过 ieee802154_sync_queue（） 阻止工作线程不受限制的 MLME TX 等待。此外，mac-command 工作线程会跳过已停止接口 （ieee802154_sdata_running（） 的处理，从而避免在拆卸过程中出现不必要的关联响应。
    (CVE-2026-97595)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

检测

Linux Distros 未修补的漏洞：CVE-2026-97595

high Nessus 插件 ID 350631

版本 1.2