Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - 藍牙：修正 l2cap_sock_cleanup_listen（） 與 l2cap_conn_del（） 中的 UAF bt_accept_dequeue（） 將尚未接受的子項與父項接受佇列解除連結，並在返回之前對其進行release_sock（）處理，因此傳回的 sk 沒有呼叫端參照並已解鎖。l2cap_sock_cleanup_listen（） 會在監聽通訊端關閉時遍歷這些子項。並行 HCI 中斷連接會驅動 hci_rx_work -> l2cap_conn_del（），它會執行 l2cap_chan_del（） + l2cap_sock_kill（） 並釋放子 sk 及其l2cap_chan;cleanup_listen（） 然後同時使用： 錯誤：KASAN：l2cap_sock_kill l2cap_sock_kill 中的 slab-use-after-free / l2cap_sock_cleanup_listen /
    __x64_sys_close 釋放者： l2cap_conn_del -> l2cap_sock_close_cb -> l2cap_sock_kill 這與此區域中已有的兩個修正不同： commit e83f5e24da741 （藍牙：序列化 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 仍被鎖定時，在 release_sock（） 之前執行 sock_hold（）;呼叫端 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 lock 下運行，這將反轉 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 Plugin ID 324896

版本 1.9