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

  - Bluetooth： SCO：為通訊端提供自己的sco_conn參照 sco_conn_del（） 會丟棄它不擁有的參照。它透過 sco_conn_hold_unless_zero（） 接受一個瞬態參照，並使用 sco_sock_hold（） 後面的 sco_conn_put（） 釋放它;！sk 分支中的額外 put 會釋放第二個：
    conn = sco_conn_hold_unless_zero（conn）;...sk = sco_sock_hold（conn）;sco_conn_unlock（conn）;
    sco_conn_put（conn）;if （！sk） { sco_conn_put（conn）; return; }當 close（） 爭用控制器的斷線完成時，sco_chan_del（） 會清除 conn->sk 並在 sco_conn_del（） 執行時刪除通訊端的參照。然後sco_conn_del（） 看到 sk == NULL，它自己的 put 將計數降至零並釋放 conn，第二個 put 寫入釋放的 kref： 錯誤： KASAN：sco_conn_put.part.0+0x1a/0x190 中的 slab-use-after-free 透過任務 kworker/u17：3/413 在 addr ffff8881099dec74 寫入大小 4 工作佇列：hci1 hci_rx_work呼叫追蹤： sco_conn_put.part.0+0x1a/0x190 hci_disconn_complete_evt+0x1ee/0x3e0 hci_event_packet+0x54a/0x650 hci_rx_work+0x321/0x3d0 由任務 413 分配： sco_conn_add+0x72/0x1a0 sco_connect_cfm+0x88/0x670 由任務 413 釋放：
    sco_conn_del.isra.0+0x3f/0xf0 hci_disconn_complete_evt+0x1ee/0x3e0 refcount_t：下溢;釋放後使用。
    根本原因是通訊端儲存連接，而沒有保留自己的參照。
    __sco_chan_add（） 會執行：sco_pi（sk）->conn = conn;因此，通訊端會借用其呼叫者碰巧持有的任何參考，而呼叫者則透過臨時保留和放置來掩蓋它。改為給通訊端一個計數引用：__sco_chan_add（） 接受一個，它與通道 （sco_chan_del（）） 和 sco_sock_destruct（） 一起釋放。由於通訊端保留自己的引用，sco_conn_del（） 不再需要額外的放置，並且 sco_conn_ready（） 中的冗餘保留消失了。讓通訊端擁有其引用意味著連接現在實際上在 sco_connect（） 的錯誤路徑上被釋放，它曾經洩漏，這反過來又運行 sco_conn_free（） 及其 hci_conn_drop（conn->hcon）。為了保持hci_conn帳戶的平衡，也要明確該所有權：sco_conn_add（） 會耗用一個hci_conn參照，而 sco_conn 在其存留期內擁有它。sco_connect（） 會移交 hci_connect_sco（） 傳回的參照，不再將其丟棄在錯誤路徑上;沒有給出引用的 sco_connect_cfm（） 在將其交給 sco_conn_add（） 之前用 hci_conn_hold（） 獲取一個（如果分配失敗，則再次刪除它）;並且 sco_conn_ready（） 中的明確 hci_conn_hold（） 會被移除。然後，每個參考文獻都有一個明確的所有者。（CVE-2026-80683）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - Bluetooth:SCO:ソケットに独自の sco_conn 参照を与えますsco_conn_del() は、ソケットが所有していない参照をドロップします。sco_conn_hold_unless_zero()を介して1つの過渡参照を受け取り、sco_sock_hold()に続くsco_conn_put()で解放します。!sk ブランチの追加配置により、2 番目の脆弱性がリリースされます:
    conn = sco_conn_hold_unless_zero(conn);...sk = sco_sock_hold(conn);sco_conn_unlock(conn);
    sco_conn_put(conn);if (!sk) { sco_conn_put(conn); return; }close() がコントローラーの切断完了と競合すると、sco_chan_del() は conn->sk をクリアし、sco_conn_del() の実行中にソケットの参照をドロップします。sco_conn_del() は次に sk == NULL と見なし、それ自体の put がカウントをゼロに落として conn を解放し、2 番目の put が解放された kref に書き込みます: バグ: KASAN:sco_conn_put.part.0+0x1a/0x190 の slab-use-after-free タスクによる addr ffff8881099dec74 でのサイズ 4 の書き込み workqueue:hci1 hci_rx_work コールトレース: sco_conn_put.part.0+0x1a/0x190 hci_disconn_complete_evt+0x1ee/0x3e0 hci_event_packet+0x54a/0x650 hci_rx_work+0x321/0x3d0 タスク413によって割り当てられる: sco_conn_add+0x72/0x1a0 sco_connect_cfm+0x88/0x670 タスク413によって解放される:
    sco_conn_del.isra.0+0x3f/0xf0 hci_disconn_complete_evt+0x1ee/0x3e0 refcount_t:アンダーフロー。use-after-free。
    根本的な原因は、ソケットが独自の参照を保持せずに接続を保存することです。
    __sco_chan_add() は以下を実行します:sco_pi(sk)->conn = conn;したがって、ソケットは、呼び出し元がたまたま保持していた参照を借用し、呼び出し元はアドホックホールドとプットでそれを覆います。代わりにソケットにカウントされた参照を与えます:__sco_chan_add() が 1 つを受け取り、それはチャネル(sco_chan_del())および sco_sock_destruct() で一緒にリリースされます。ソケットが独自の参照を保持することで、sco_conn_del() は追加の put を必要としなくなり、sco_conn_ready() の冗長な保留はなくなります。ソケットに独自の参照を所有させるということは、接続が、以前漏洩していた sco_connect() のエラーパスで実際に解放されることを意味します。これにより、sco_conn_free() とその hci_conn_drop(conn->hcon) が実行されます。hci_connアカウンティングのバランスを保つには、その所有権も明示的にします。sco_conn_add() は 1 つのhci_conn参照を消費し、sco_connはその存続期間中それを所有します。sco_connect() は hci_connect_sco() から返された参照を引き渡し、それをエラーパスにドロップしなくなりました。参照が与えられていない sco_connect_cfm() は、sco_conn_add() に渡す前に hci_conn_hold() で 1 つを取得します (そして、割り当てに失敗した場合はもう一度ドロップします)。sco_conn_ready() の明示的な hci_conn_hold() は削除されます。すべての参照には、単一の明確な所有者があります。(CVE-2026-80683)

Nessus は、ベンダーから報告されたパッケージの存在に依存していることに注意してください。

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

  - Bluetooth：SCO：为套接字提供自己的sco_conn引用 sco_conn_del（） 丢弃它不拥有的引用。它通过 sco_conn_hold_unless_zero（） 获取一个瞬态引用，并使用 sco_sock_hold（） 后面的 sco_conn_put（） 将其释放;！sk 分支中的附加版本会发布第二个更新：
    conn = sco_conn_hold_unless_zero（conn）;...sk = sco_sock_hold（conn）;sco_conn_unlock（conn）;
    sco_conn_put（conn）;if （！sk） { sco_conn_put（conn）; return; }当 close（） 与控制器的 Disconnect Complete 争用时，sco_chan_del（） 会在运行 sco_conn_del（） 时清除 conn->sk 并丢弃套接字的引用。然后，sco_conn_del（） 看到 sk == NULL，其自身的放置将计数降至零并释放 conn，第二个放置写入已释放的 kref： 缺陷： KASAN：sco_conn_put.part.0+0x1a/0x190 中的 slab-use-after-free 通过任务 kworker/u17：3/413 在地址 ffff8881099dec74 处写入大小为 4 工作队列：hci1 hci_rx_work调用跟踪： sco_conn_put.part.0+0x1a/0x190 hci_disconn_complete_evt+0x1ee/0x3e0 hci_event_packet+0x54a/0x650 hci_rx_work+0x321/0x3d0 按任务 413 分配：sco_conn_add+0x72/0x1a0 sco_connect_cfm+0x88/0x670 由任务 413 释放：
    sco_conn_del.isra.0+0x3f/0xf0 hci_disconn_complete_evt+0x1ee/0x3e0 refcount_t：下溢;释放后使用。
    根本原因是套接字存储连接时不持有自己的引用。
    __sco_chan_add（） 执行：sco_pi（sk）->conn = conn;因此，套接字借用其调用者碰巧持有的任何引用，而调用者则通过临时持有和放置来覆盖它。请改为为套接字提供计数引用：__sco_chan_add（） 采用一个，它与通道 （sco_chan_del（）） 和 sco_sock_destruct（） 中一起释放。由于套接字保留了自己的引用，sco_conn_del（） 不再需要额外的放置，并且 sco_conn_ready（） 中的冗余保持消失了。使套接字拥有自己的引用意味着现在在 sco_connect（） 的错误路径上实际释放连接，其中曾经泄漏，而 sco_conn_free（） 及其 hci_conn_drop（conn->hcon）。为了保持hci_conn核算的平衡，还要明确该所有权：sco_conn_add（） 使用一个hci_conn引用，sco_conn在其生命周期内拥有它。sco_connect（） 移交 hci_connect_sco（） 返回的引用，不再将其丢弃在错误路径中;没有给出引用的 sco_connect_cfm（） 在将 hci_conn_hold（） 传递给 sco_conn_add（） 之前使用它（如果分配失败，则再次删除它）;并且删除了 sco_conn_ready（） 中的显式 hci_conn_hold（）。然后，每个参考都有一个明确的所有者。（CVE-2026-80683）

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

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - Bluetooth: SCO: give the socket its own sco_conn reference sco_conn_del() drops a reference it does not     own. It takes one transient reference via sco_conn_hold_unless_zero() and releases it with the     sco_conn_put() that follows sco_sock_hold(); the additional put in the !sk branch releases a second one:
    conn = sco_conn_hold_unless_zero(conn); ... sk = sco_sock_hold(conn); sco_conn_unlock(conn);
    sco_conn_put(conn); if (!sk) { sco_conn_put(conn); return; } When close() races the controller's     Disconnection Complete, sco_chan_del() clears conn->sk and drops the socket's reference while     sco_conn_del() is running. sco_conn_del() then sees sk == NULL, its own put drops the count to zero and     frees the conn, and the second put writes to the freed kref: BUG: KASAN: slab-use-after-free in     sco_conn_put.part.0+0x1a/0x190 Write of size 4 at addr ffff8881099dec74 by task kworker/u17:3/413     Workqueue: hci1 hci_rx_work Call Trace: sco_conn_put.part.0+0x1a/0x190     hci_disconn_complete_evt+0x1ee/0x3e0 hci_event_packet+0x54a/0x650 hci_rx_work+0x321/0x3d0 Allocated by     task 413: sco_conn_add+0x72/0x1a0 sco_connect_cfm+0x88/0x670 Freed by task 413:
    sco_conn_del.isra.0+0x3f/0xf0 hci_disconn_complete_evt+0x1ee/0x3e0 refcount_t: underflow; use-after-free.
    The root cause is that the socket stores the connection without holding a reference of its own.
    __sco_chan_add() does: sco_pi(sk)->conn = conn; so the socket borrows whatever reference its caller     happened to hold, and the callers paper over that with ad-hoc holds and puts. Give the socket a counted     reference instead: __sco_chan_add() takes one and it is released together with the channel     (sco_chan_del()) and in sco_sock_destruct(). With the socket holding its own reference, sco_conn_del() no     longer needs the extra put and the redundant hold in sco_conn_ready() goes away. Making the socket own its     reference means the connection is now actually freed on the error paths of sco_connect() where it used to     leak, which in turn runs sco_conn_free() and its hci_conn_drop(conn->hcon). To keep the hci_conn     accounting balanced, make that ownership explicit as well: sco_conn_add() consumes one hci_conn reference     and the sco_conn owns it for its lifetime. sco_connect() hands over the reference returned by     hci_connect_sco() and no longer drops it on the error paths; sco_connect_cfm(), which is not given a     reference, takes one with hci_conn_hold() before handing it to sco_conn_add() (and drops it again if the     allocation fails); and the explicit hci_conn_hold() in sco_conn_ready() is removed. Every reference then     has a single, clear owner. (CVE-2026-80683)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Published	Updated	Severity
341917	Linux Distros 未修補弱點：CVE-2026-80683	Nessus	Misc.	8/31/2026	9/2/2026	high
341917	Linux Distros のパッチ未適用の脆弱性: CVE-2026-80683	Nessus	Misc.	8/31/2026	9/2/2026	high
341917	Linux Distros 未修补的漏洞：CVE-2026-80683	Nessus	Misc.	8/31/2026	9/2/2026	high
341917	Linux Distros Unpatched Vulnerability : CVE-2026-80683	Nessus	Misc.	8/31/2026	9/2/2026	high

Detections

Analytics

Plugins Search

high

high

high

high