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

  - fuse-uring：修正註冊和連線中止之間的爭用 這修正了此爭用： - 執行緒 A：
    io_uring_enter -> register sqe -> fuse_uring_create_ring_ent -> 分配 ent，但尚未抓取queue_ref - 執行緒 b：fuse_conn_destroy（） -> fuse_chan_abort（） -> fuse_uring_abort（） 由於佇列引用為 0，因此無操作 - 執行緒 a：抓取queue_ref，queue_ref現在是 1，其餘的 fuse_uring_do_register（） 邏輯執行 - 執行緒 b： fuse_chan_abort（） 傳回，fuse_chan_wait_aborted（） 現在會執行並呼叫 wait_event（ring->stop_waitq， atomic_read（&ring->queue_refs） == 0）;中止/卸載執行緒將在不可終止狀態下無限懸置，因為沒有任何內容不會遞減queue_refs或喚醒stop_waitq，並且環、佇列和 ent 會洩漏。在建立的 ent 取得佇列上的參照計數後，檢查 fch->lock 下的 fch->connected 來解決此問題。這樣可以確保在上述案例中，當我們偵測到 ！fch->connected 時，可以保證我們在 fuse_uring_do_register（） 中釋放佇列 ref 並喚醒 stop_waitq （如果 fuse_chan_wait_aborted（） 已經在等待），或者如果檢查後連線中止，則可以保證非同步拆卸工作程式將在背景運行，清理 ents 並遞減佇列上 ent 的 ref， 這將解除封鎖最終佇列並關閉環形。
    (CVE-2026-68095)

請注意，Nessus 依賴供應商報告的套件存在。

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

  - fuse-uring：修复注册和连接中止之间的争用 这可修复此争用：- 线程 a：
    io_uring_enter -> register sqe -> fuse_uring_create_ring_ent -> 分配 ent，但尚未抓取queue_ref - 线程 b： fuse_conn_destroy（） -> fuse_chan_abort（） -> fuse_uring_abort（） 为无 op，因为队列引用为 0 - 线程 a：获取queue_ref，queue_ref现在为 1，其余 fuse_uring_do_register（） 逻辑执行 - 线程 b： fuse_chan_abort（） 返回时，fuse_chan_wait_aborted（） 现在运行并调用 wait_event（ring->stop_waitq， atomic_read（&ring->queue_refs） == 0）;中止/卸载线程将无限期挂起处于无法终止的状态，因为不会减少queue_refs或唤醒stop_waitq，并且会泄漏环、队列和 ent。通过在创建的 ent 获取队列中的 ref 计数后检查 fch->lock 下的 fch->connected 来修复此问题。这确保了在上述情况下，当我们检测到 ！fch->connected 时，可以保证我们在 fuse_uring_do_register（） 中释放队列 ref 并唤醒stop_waitq（如果 fuse_chan_wait_aborted（） 已经在等待），或者如果在检查后中止连接，则可以保证异步拆卸工作线程将在后台运行，清理 ents 并递减队列上 ent's ref， 这将取消阻断最终队列并环拆卸。
    (CVE-2026-68095)

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

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

  - fuse-uring:登録と接続中止の間の競合を修正します。これはこの競合を修正します: - スレッド A:
    io_uring_enter -> register sqe -> fuse_uring_create_ring_ent -> ent を割り当てるが、まだqueue_refを取得しません - スレッド b: fuse_conn_destroy() -> fuse_chan_abort() -> fuse_uring_abort() はキュー ref が 0 であるため no-op です - スレッド A: queue_ref を入手します、queue_ref は現在 1 です、残りの fuse_uring_do_register() ロジックが実行されます - スレッド b: fuse_chan_abort() が返されると、fuse_chan_wait_aborted() が実行され、wait_event(ring->stop_waitq, atomic_read(&ring->queue_refs) == 0);何も queue_refs を減らしたり、stop_waitqを起動したりしないために、中止/マウント解除のスレッドは kill できない状態で無期限にハングし、リング、キュー、ent が漏洩します。作成された ent がキューで参照カウントを取得した後で、fch->lock 下の fch->connected をチェックすることにより、これを修正します。これにより、上記のシナリオで、!fch->connected を検出したときにキュー ref をリリースし、fuse_uring_do_register() で stop_waitq をウェイクアップするか (fuse_chan_wait_aborted() がすでに待機している場合)、またはチェック後に接続が中断された場合、 async teardown ワーカーがバックグラウンドで実行され、ents がクリーンアップされ、キュー上の ent の ref を減少することが保証されます。 これにより、最終的なキューとリング切断のブロックが解除されます。
    (CVE-2026-68095)

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

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

  - fuse-uring: fix race between registration and connection abortion This fixes this race: - thread a:
    io_uring_enter -> register sqe -> fuse_uring_create_ring_ent -> allocate ent but doesn't grab queue_ref     yet - thread b: fuse_conn_destroy() -> fuse_chan_abort() -> fuse_uring_abort() is a no-op due to queue ref     being 0 - thread a: grabs the queue_ref, queue_ref is now 1, rest of fuse_uring_do_register() logic     executes - thread b: fuse_chan_abort() returns, fuse_chan_wait_aborted() now runs and calls     wait_event(ring->stop_waitq, atomic_read(&ring->queue_refs) == 0); The abort/unmount thread will hang     indefinitely in unkillable state as nothing will decrement queue_refs or wake stop_waitq, and the ring,     queue, and ent are leaked. Fix this by checking fch->connected under fch->lock after the created ent has     grabbed a ref count on the queue. This ensures that in the scenario above, it is guaranteed that we either     release the queue ref and wake up stop_waitq (in case fuse_chan_wait_aborted() is already waiting) in     fuse_uring_do_register() when we detect !fch->connected, or if the connection is aborted after the check,     it is guaranteed that the async teardown worker will be running in the background cleaning up ents and     decrementing the ent's ref on the queue, which will unblock the eventual queue and ring teardown.
    (CVE-2026-68095)

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

ID	Name	Product	Family	Published	Updated	Severity
341888	Amazon Linux 2023：bpftool6.18、kernel6.18、kernel6.18-devel (ALAS2023-2026-2106)	Nessus	Amazon Linux Local Security Checks	8/31/2026	9/1/2026	high
334874	Linux Distros 未修補弱點：CVE-2026-68095	Nessus	Misc.	8/12/2026	8/27/2026	medium
341888	Amazon Linux 2023 : bpftool6.18、kernel6.18、kernel6.18-devel (ALAS2023-2026-2106)	Nessus	Amazon Linux Local Security Checks	8/31/2026	9/1/2026	high
341888	Amazon Linux 2023：bpftool6.18、kernel6.18、kernel6.18-devel (ALAS2023-2026-2106)	Nessus	Amazon Linux Local Security Checks	8/31/2026	9/1/2026	high
334874	Linux Distros 未修补的漏洞：CVE-2026-68095	Nessus	Misc.	8/12/2026	8/27/2026	medium
334874	Linux Distros のパッチ未適用の脆弱性: CVE-2026-68095	Nessus	Misc.	8/12/2026	8/27/2026	medium
341888	Amazon Linux 2023 : bpftool6.18, kernel6.18, kernel6.18-devel (ALAS2023-2026-2106)	Nessus	Amazon Linux Local Security Checks	8/31/2026	9/1/2026	high
334874	Linux Distros Unpatched Vulnerability : CVE-2026-68095	Nessus	Misc.	8/12/2026	8/27/2026	medium

Detections

Analytics

Plugins Search

high

medium

high

high

medium

medium

high

medium