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

  - Bluetooth：修复 l2cap_sock_cleanup_listen（） 与 l2cap_conn_del（） 中的 UAF bt_accept_dequeue（） 将尚未接受的子项与父接受队列断开链接，并在返回前对其进行 release_sock（）s，这样返回的 sk 就没有调用程序引用并解锁。l2cap_sock_cleanup_listen（） 在监听套接字关闭时遍历这些子项。并行 HCI 断开连接驱动运行 l2cap_chan_del（） + l2cap_sock_kill（） 的 hci_rx_work -> l2cap_conn_del（） 并释放子 sk 及其l2cap_chan;然后，cleanup_listen（） 使用两者： 缺陷：KASAN：l2cap_sock_kill l2cap_sock_kill / l2cap_sock_cleanup_listen / 中的 slab-after-free 使用
    __x64_sys_close 释放者：l2cap_conn_del -> l2cap_sock_close_cb -> l2cap_sock_kill 这与该区域已有的两个补丁不同：提交 e83f5e24da741（Bluetooth：序列化 accept_q 访问）序列化 accept_q 列表/轮询并在 bt_accept_dequeue（） 中获取临时引用，并通过 CVE-2025-39860 调用 l2cap_sock_release（） 中的 lock_sock（） 下的 cleanup_listen（） 序列化用户空间 close（）/accept（） 争用。两者都不涵盖从hci_rx_work运行的 l2cap_conn_del（），因此此 UAF 仍在当前蓝牙/主控上重现。获取源代码的参考：bt_accept_dequeue（） 在 sk 仍处于锁定状态时执行 sock_hold（），在 release_sock（） 之前;调用程序 sock_put（）。cleanup_listen（） 将带有 l2cap_chan_hold_unless_zero（） 的 chan 固定在简短的子 sk 锁定（序列化与 l2cap_sock_teardown_cb（））下，在 l2cap_chan_lock（） 之前将其丢弃，然后跳过 SOCK_DEAD 上的重复 l2cap_sock_kill（）。此处不采用 conn->lock：cleanup_listen（） 在父 sk 锁定下运行，这会反转 conn->lock ->chan->lock -> sk_lock （lockdep）。KASAN/SMP：在此变更之前，非特权监听/关闭与 HCI 断开连接的争用每次运行都会产生 12 个释放后使用报告;0，并且没有 lockdep 报告，之后在蓝牙/主控上进行了超过 1600+ 次争用迭代。（CVE-2026-53357）

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

检测

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

high Nessus 插件 ID 324896

版本 1.13