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

  - vsock/virtio上限 TX 贷项本地缓冲区大小 virtio 传输直接从 peer_buf_alloc 获取其 TX 贷项peer_buf_alloc是根据远程端点的 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 进程后恢复。即使如此如果 cgroups 限制 QEMU 内存所使用的最大内存也将受到限制。应用此修补程序之后 之前MemFree: ~61.6 GiB Slab: ~142 MiB SUnreclaim: ~117 MiB After 32 高信用连接 MemFree: ~61.5 GiB Slab: ~178 MiB SUnreclaim
    Slab/SUnreclaim 中仅增加约 152 MiB 约 35 MiB，无主机 OOM，客户机保持响应。
    与非 virtio 传输的兼容性 - VMCI 使用 AF_VSOCK 缓冲区旋钮根据本地 vsk->buffer_* 值调整每个套接字的队列对大小远程端无法将这些队列扩大到本地端点所配置的范围之外。- Hyper-V 的 vsock 传输使用固定大小的 VMBus 环形缓冲区和 MTU 边界不存在可与 peer_buf_alloc 比较的对等机控制的 credit 字段并且远程端点无法将传输中的内核内存驱动到这些环大小以上。- 环回路径重用 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 插件 ID 297921

版本 1.18