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

medium Tenable Self-Hosted Container Security Plugin ID 472456

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: netfilter: nf_conntrack: fix crash due
to removal of uninitialised entry A crash in conntrack was reported while trying to unlink the conntrack
entry from the hash bucket list: [exception RIP: __nf_ct_delete_from_lists+172] [..] #7 [ff539b5a2b043aa0]
nf_ct_delete at ffffffffc124d421 [nf_conntrack] #8 [ff539b5a2b043ad0] nf_ct_gc_expired at ffffffffc124d999
[nf_conntrack] #9 [ff539b5a2b043ae0] __nf_conntrack_find_get at ffffffffc124efbc [nf_conntrack] [..] The
nf_conn struct is marked as allocated from slab but appears to be in a partially initialised state: ct
hlist pointer is garbage; looks like the ct hash value (hence crash). ct->status is equal to
IPS_CONFIRMED|IPS_DYING, which is expected ct->timeout is 30000 (=30s), which is unexpected. Everything
else looks like normal udp conntrack entry. If we ignore ct->status and pretend its 0, the entry matches
those that are newly allocated but not yet inserted into the hash: - ct hlist pointers are overloaded and
store/cache the raw tuple hash - ct->timeout matches the relative time expected for a new udp flow rather
than the absolute 'jiffies' value. If it were not for the presence of IPS_CONFIRMED,
__nf_conntrack_find_get() would have skipped the entry. Theory is that we did hit following race: cpu x
cpu y cpu z found entry E found entry E E is expired <preemption> nf_ct_delete() return E to rcu slab
init_conntrack E is re-inited, ct->status set to 0 reply tuplehash hnnode.pprev stores hash value. cpu y
found E right before it was deleted on cpu x. E is now re-inited on cpu z. cpu y was preempted before
checking for expiry and/or confirm bit. ->refcnt set to 1 E now owned by skb ->timeout set to 30000 If cpu
y were to resume now, it would observe E as expired but would skip E due to missing CONFIRMED bit.
nf_conntrack_confirm gets called sets: ct->status |= CONFIRMED This is wrong: E is not yet added to
hashtable. cpu y resumes, it observes E as expired but CONFIRMED: <resumes> nf_ct_expired() -> yes
(ct->timeout is 30s) confirmed bit set. cpu y will try to delete E from the hashtable: nf_ct_delete() ->
set DYING bit __nf_ct_delete_from_lists Even this scenario doesn't guarantee a crash: cpu z still holds
the table bucket lock(s) so y blocks: wait for spinlock held by z CONFIRMED is set but there is no
guarantee ct will be added to hash: "chaintoolong" or "clash resolution" logic both skip the insert step.
reply hnnode.pprev still stores the hash value. unlocks spinlock return NF_DROP <unblocks, then crashes on
hlist_nulls_del_rcu pprev> In case CPU z does insert the entry into the hashtable, cpu y will unlink E
again right away but no crash occurs. Without 'cpu y' race, 'garbage' hlist is of no consequence: ct
refcnt remains at 1, eventually skb will be free'd and E gets destroyed via: nf_conntrack_put ->
nf_conntrack_destroy -> nf_ct_destroy. To resolve this, move the IPS_CONFIRMED assignment after the table
insertion but before the unlock. Pablo points out that the confirm-bit-store could be reordered to happen
before hlist add resp. the timeout fixup, so switch to set_bit and before_atomic memory barrier to prevent
this. It doesn't matter if other CPUs can observe a newly inserted entry right before the CONFIRMED bit
was set: Such event cannot be distinguished from above "E is the old incarnation" case: the entry will be
skipped. Also change nf_ct_should_gc() to first check the confirmed bit. The gc sequence is: 1. Check if
entry has expired, if not skip to next entry 2. Obtain a reference to the expired entry. 3. Call
nf_ct_should_gc() to double-check step 1. nf_ct_should_gc() is thus called only for entries that already
failed an expiry check. After this patch, once the confirmed bit check pas ---truncated---
(CVE-2025-38472)

Solution

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

Plugin Details

Severity: Medium

ID: 472456

Version: Revision 1.1

Type: Local

Family: Google COS Security Checks

Published: 10/3/2026

Updated: 10/3/2026

Risk Information

VPR

Risk Factor: Low

Score: 3

Percentile: 23.35

Vendor

Vendor Severity: LOW

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-2025-38472

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: 7/28/2025

Reference Information

CVE: CVE-2025-38472

Detections

Analytics