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

critical Tenable Self-Hosted Container Security Plugin ID 469296

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: net/handshake: Drain pending requests
at net namespace exit The arguments to list_splice_init() in handshake_net_exit() are reversed. The call
moves the local empty "requests" list onto hn->hn_requests, leaving the local list empty, so the
subsequent drain loop runs zero iterations. Pending handshake requests that had not yet been accepted are
not torn down when the net namespace is destroyed; each one keeps a reference on a socket file and on the
handshake_req allocation. Pass the source and destination in the documented order (list_splice_init(list,
head) moves list onto head) so the pending list is transferred to the local scratch list and drained
through handshake_complete(). Fixing the splice direction exposes a list-corruption race. After the splice
each req->hr_list still has non-empty link pointers, threading the stack-local scratch list rather than
hn_requests. A concurrent handshake_req_cancel() -- for example, from sunrpc's TLS timeout on a kernel
socket whose netns reference was not taken -- finds the request through the rhashtable, calls
remove_pending(), and sees !list_empty(&req->hr_list). __remove_pending_locked() then list_del_init()s an
entry off the scratch list while the drain iterates, corrupting it. The same call arriving after the drain
loop has run list_del() on an entry hits LIST_POISON instead. Have remove_pending() check
HANDSHAKE_F_NET_DRAINING under hn_lock and report not-found when drain is in progress. The drain has
already taken ownership; handshake_complete()'s existing test_and_set on HANDSHAKE_F_REQ_COMPLETED still
arbitrates between drain and cancel for who calls the consumer's hp_done. Use list_del_init() rather than
list_del() in the drain so req->hr_list does not carry LIST_POISON after drain releases the entry. The
DRAINING guard in remove_pending() makes cancel return false, but cancel still falls through to
test_and_set_bit on HANDSHAKE_F_REQ_COMPLETED and drops the request's hr_file reference. Without another
pin, if that is the last reference, sk_destruct frees the request while it is still linked on the drain
loop's local list. Pin each request's hr_file under hn_lock before releasing the list, and drop that drain
pin after the loop finishes with the request. (CVE-2026-63978)

Solution

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

Plugin Details

Severity: Critical

ID: 469296

Version: Revision 1.4

Type: Local

Family: Google COS Security Checks

Published: 10/3/2026

Updated: 10/5/2026

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

Risk Information

VPR

Risk Factor: Medium

Score: 4.9

Percentile: 58.15

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-63978

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: 6/25/2026

Reference Information

CVE: CVE-2026-63978

Detections

Analytics