Google: sys-kernel/cchost-kernel-6_12, sys-kernel/cchost-kernel-6_18, sys-kernel/csql-kernel-6_12, sys-kernel/csql-kernel-6_18, sys-kernel/lakitu-kernel-6_12, sys-kernel/lakitu-kernel-6_18, sys-kernel/lakitu-nc-kernel-6_12, sys-kernel/lakitu-nc-kernel-6_18: security update to 19999.44.21

critical Tenable Cloud Security Plugin ID 470551

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: xprtrdma: Fix bcall rep leak and
unbounded peek rpcrdma_is_bcall() decodes a reply's first words to decide whether the frame is a
backchannel call. Two issues in that decode path let a short or malformed reply leak the receive buffer
and drain the Receive queue. First, the speculative peek p = xdr_inline_decode(xdr, 0); /* five p++ reads
follow */ asks xdr_inline_decode() for zero bytes, which returns xdr->p without consulting xdr->end. The
five subsequent __be32 reads can then walk up to 20 bytes past the wire payload into stale regbuf contents
and misclassify the reply as a backchannel call. Second, after the post-peek p = xdr_inline_decode(xdr, 3
* sizeof(*p)); if (unlikely(!p)) return true; the short-header arm returns true without calling
rpcrdma_bc_receive_call(). The contract with the caller is that a true return transfers ownership of rep
to the backchannel path: rpcrdma_reply_handler() if (rpcrdma_is_bcall(r_xprt, rep)) return; /* bare
return, skips out_post */ ... out_post: rpcrdma_post_recvs(r_xprt, credits + ...); Because
rpcrdma_bc_receive_call() never ran, no one took rep, but rpcrdma_reply_handler still bare-returns past
rpcrdma_rep_put() and rpcrdma_post_recvs(). The rep, with its persistently DMA-mapped receive buffer, is
orphaned on rb_all_reps and freed only at transport teardown. This completion reposts nothing, so its slot
is reclaimed only when a later forward-channel reply reaches out_post and rpcrdma_post_recvs() allocates a
fresh rep to backfill; absent that traffic the Receive queue drains and the peer's Sends draw RNR NAKs.
Fix by consulting xdr->end after the zero-length peek so the five __be32 reads cannot run unless 20 bytes
of wire payload remain. A byte-precise comparison against xdr->end is required because a non-4-aligned
receive rounds the stream's word count up past the true payload. Also return false from the short-header
arm so the reply falls through the normal out_norqst cleanup chain (rpcrdma_rep_put() plus
rpcrdma_post_recvs()). (CVE-2026-72466)

Solution

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

Plugin Details

Severity: Critical

ID: 470551

Version: Revision 1.6

Type: Local

Family: Google COS Security Checks

Published: 10/3/2026

Updated: 10/6/2026

Supported Sensors: Tenable Cloud Security, Tenable Self-Hosted Container Security

Risk Information

VPR

Risk Factor: Medium

Score: 4.9

Percentile: 58.27

Vendor

Vendor Severity: LOW

CVSS v2

Risk Factor: Critical

Base Score: 10

Temporal Score: 7.4

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

CVSS Score Source: CVE-2026-72466

CVSS v3

Risk Factor: Critical

Base Score: 9.8

Temporal Score: 8.5

Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/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: 8/11/2026

Reference Information

CVE: CVE-2026-72466

Detections

Analytics