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

critical Tenable Cloud Security Plugin ID 470112

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: tcp: defer md5sig_info kfree past RCU
grace period in tcp_connect The md5+ao reconciliation in tcp_connect() (net/ipv4/tcp_output.c) has two
symmetric branches: if (needs_md5) { tcp_ao_destroy_sock(sk, false); } else if (needs_ao) {
tcp_clear_md5_list(sk); kfree(rcu_replace_pointer(tp->md5sig_info, NULL, ...)); } Both branches free a
per-socket auth-info object while the socket is in TCP_SYN_SENT and is already on the inet ehash (inserted
by inet_hash_connect() in tcp_v4_connect()). Both branches are reachable by softirq RX-path readers that
load the corresponding info pointer via implicit RCU before bh_lock_sock_nested() is taken. The needs_md5
branch is fixed in the prior patch by re-introducing the call_rcu() free in tcp_ao_destroy_sock(): the
equivalent per-key loop runs inside tcp_ao_info_free_rcu(), the RCU callback, so by the time it frees each
tcp_ao_key all softirq readers that captured the container have already completed rcu_read_unlock(). The
needs_ao branch is not symmetric in the same way. The container free can be deferred via kfree_rcu(md5sig,
rcu) -- struct tcp_md5sig_info already has the required rcu member (include/net/tcp.h:1999-2002), and the
rest of the tree already does this in the tcp_md5sig_info_add() rollback paths (net/ipv4/tcp_ipv4.c:1410,
1436). But the per-key teardown is done by tcp_clear_md5_list() in process context BEFORE the container's
RCU grace period: it walks &md5sig->head and frees each tcp_md5sig_key with bare hlist_del + kfree. A
concurrent softirq reader in __tcp_md5_do_lookup() / __tcp_md5_do_lookup_exact() (tcp_ipv4.c:1253, 1298)
walks the same list via hlist_for_each_entry_rcu() and races with that bare kfree on the keys themselves
-- a per-key slab use-after-free of the same class as the TCP-AO bug, on the same race window. Fix this in
two halves: 1. Convert the bare kfree() in tcp_connect() to kfree_rcu() so the md5sig_info container joins
the rest of the md5sig lifecycle. The local-variable lift is mechanical and required because kfree_rcu()
is a macro that expects an lvalue. 2. Make tcp_clear_md5_list() RCU-safe by replacing hlist_del +
kfree(key) with hlist_del_rcu + kfree_rcu(key, rcu). struct tcp_md5sig_key already carries the rcu member
(include/net/tcp.h:1995) and tcp_md5_do_del() (net/ipv4/tcp_ipv4.c:1456) already uses kfree_rcu, so this
restores the lifecycle invariant the rest of the file follows rather than introducing a one-off. The other
caller of tcp_clear_md5_list() is tcp_md5_destruct_sock() (net/ipv4/tcp.c:412), which runs from the sock
destructor when the socket is already unhashed and unreachable; the extra grace period there is
unnecessary but harmless. Making the helper unconditionally RCU-safe is the cleaner contract. The needs_ao
branch is not reachable by the userns reproducer used to demonstrate the AO-side splat (the repro installs
both keys but ends up in the needs_md5 branch because the connect peer matches the MD5 key, not the AO
key); however the symmetric race exists and a maintainer touching this code should not have to think about
which branch escapes RCU and which one does not. [also credits to Qihang, who found that this races with
tcp-diag] (CVE-2026-72139)

Solution

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

See Also

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

Plugin Details

Severity: Critical

ID: 470112

Version: Revision 1.6

Type: Local

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.12

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

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