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

  - vsock/virtio將 TX 認可設定為本機緩衝區大小。virtio 傳輸直接從 peer_buf_alloc 取得其 TX 認可而後者是從遠端端點的 SO_VM_SOCKETS_BUFFER_SIZE 值設定。在主機端這表示我們願意為連線排入佇列的資料量是由來賓選擇的緩衝區大小而非主機本身的 vsock 組態調整的。惡意來賓可公告大型緩衝區及緩慢讀取造成主機配置對應大量的 sk_buff 記憶體。由於 virtio 傳輸共用相同的程式碼基底因此具有惡意主機的來賓也會發生相同情形。引入小型協助程式 virtio_transport_tx_buf_size()可傳回 min(peer_buf_alloc, buf_alloc)並在消耗 peer_buf_alloc 的任何地方使用。這可確保有效的 TX 視窗同時受到對等端通告的緩衝區和我們自己的 buf_alloc (已透過 SO_VM_SOCKETS_BUFFER_MAX_SIZE 限制為 buffer_max_size) 限制因此遠端對等端無法強制另一個對等端將超過其 vsock 設定所允許之更多的資料排入佇列。在未修補的 Ubuntu 22.04 主機 (~64 GiB RAM) 上執行具有 32 個來賓 vsock 連線的 PoC，每個連線通告 2 GiB且讀取緩慢，會將 Slab/SUnreclaim 從 ~0.5 GiB 推至 ~57 GiB；系統只會在終止 QEMU 處理程序後復原。也就是說如果 QEMU 記憶體受到 cgroups 的限制則記憶體使用上限也會受到限制。套用此修補程式之後之前MemFree ~61.6 GiB Slab ~142 MiB SUnreclaim ~117 MiB After 32 high-credit 連線MemFree~61.5 GiB Slab ~178 MiB SUnreclaim
    僅增加 ~152 MiB Slab/SUnreclaim 中僅增加約 35 MiB無主機 OOM且來賓保持回應。
    與非 virtio 傳輸的相容性- VMCI 使用 AF_VSOCK 緩衝區 knob根據本機 vsk->buffer_* 值來調整每個通訊端的佇列組大小遠端無法將這些佇列擴大到超出本機端點的設定範圍。- Hyper-V 的 vsock 傳輸使用固定大小的 VMBus 環緩衝區和 MTU 邊界沒有可與 peer_buf_alloc 比較的對等控制信任欄位且遠端端點無法驅動超過這些環大小的傳輸核心記憶體。- 回送路徑會重複使用 virtio_transport_common.c因此自然會遵循與 virtio 傳輸相同的語意。此變更僅限於 virtio_transport_common.c因此會影響 virtio-vsock、vhost-vsock 和 loopback使其與 VMCI 和 Hyper-V 已有效擁有的本機原則行為相交的遠端視窗一致。[Stefano變更先前修補程式後的小調整] [Stefano調整提交訊息] (CVE-2026-23086)

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

偵測

Linux Distros 未修補的弱點：CVE-2026-23086

medium Nessus Plugin ID 297921

版本 1.17