Detections
Analytics

Google: sys-kernel/cchost-kernel-6_12, sys-kernel/csql-kernel-6_6: security update to 19216.220.9

medium Tenable Cloud Security Plugin ID 472116

Description

There are packages installed that are affected by a vulnerability referenced in the following CVE:

 - In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: cap TX credit to local
 buffer size The virtio transports derives its TX credit directly from peer_buf_alloc, which is set from
 the remote endpoint's SO_VM_SOCKETS_BUFFER_SIZE value. On the host side this means that the amount of data
 we are willing to queue for a connection is scaled by a guest-chosen buffer size, rather than the host's
 own vsock configuration. A malicious guest can advertise a large buffer and read slowly, causing the host
 to allocate a correspondingly large amount of sk_buff memory. The same thing would happen in the guest
 with a malicious host, since virtio transports share the same code base. Introduce a small helper,
 virtio_transport_tx_buf_size(), that returns min(peer_buf_alloc, buf_alloc), and use it wherever we
 consume peer_buf_alloc. This ensures the effective TX window is bounded by both the peer's advertised
 buffer and our own buf_alloc (already clamped to buffer_max_size via SO_VM_SOCKETS_BUFFER_MAX_SIZE), so a
 remote peer cannot force the other to queue more data than allowed by its own vsock settings. On an
 unpatched Ubuntu 22.04 host (~64 GiB RAM), running a PoC with 32 guest vsock connections advertising 2 GiB
 each and reading slowly drove Slab/SUnreclaim from ~0.5 GiB to ~57 GiB; the system only recovered after
 killing the QEMU process. That said, if QEMU memory is limited with cgroups, the maximum memory used will
 be limited. With this patch applied: Before: MemFree: ~61.6 GiB Slab: ~142 MiB SUnreclaim: ~117 MiB After
 32 high-credit connections: MemFree: ~61.5 GiB Slab: ~178 MiB SUnreclaim: ~152 MiB Only ~35 MiB increase
 in Slab/SUnreclaim, no host OOM, and the guest remains responsive. Compatibility with non-virtio
 transports: - VMCI uses the AF_VSOCK buffer knobs to size its queue pairs per socket based on the local
 vsk->buffer_* values; the remote side cannot enlarge those queues beyond what the local endpoint
 configured. - Hyper-V's vsock transport uses fixed-size VMBus ring buffers and an MTU bound; there is no
 peer-controlled credit field comparable to peer_buf_alloc, and the remote endpoint cannot drive in-flight
 kernel memory above those ring sizes. - The loopback path reuses virtio_transport_common.c, so it
 naturally follows the same semantics as the virtio transport. This change is limited to
 virtio_transport_common.c and thus affects virtio-vsock, vhost-vsock, and loopback, bringing them in line
 with the "remote window intersected with local policy" behaviour that VMCI and Hyper-V already effectively
 have. [Stefano: small adjustments after changing the previous patch] [Stefano: tweak the commit message]
 (CVE-2026-23086)

Solution

Update the sys-kernel/cchost-kernel-6_12 library and its related packages to version 19216.220.9 or later.

See Also

https://storage.googleapis.com/cos-oval-vulnerability-feed/cos-125.oval.xml.tar.gz

Plugin Details

Severity: Medium

ID: 472116

Version: Revision 1.2

Type: Local

Published: 10/3/2026

Updated: 10/3/2026

Risk Information

VPR

Risk Factor: Medium

Score: 5.7

Percentile: 96.66

Vendor

Vendor Severity: MEDIUM

CVSS v2

Risk Factor: Medium

Base Score: 4.6

Temporal Score: 3.4

Vector: CVSS2#AV:L/AC:L/Au:S/C:N/I:N/A:C

CVSS Score Source: CVE-2026-23086

CVSS v3

Risk Factor: Medium

Base Score: 5.5

Temporal Score: 4.8

Vector: CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Temporal Vector: CVSS:3.0/E:U/RL:O/RC:C

Vulnerability Information

Exploit Ease: No known exploits are available

Vulnerability Publication Date: 2/4/2026

Reference Information

CVE: CVE-2026-23086