Google: sys-kernel/csql-kernel-6_1, sys-kernel/csql-kernel-6_6, sys-kernel/lakitu-kernel-6_1, sys-kernel/lakitu-kernel-6_6, sys-kernel/lakitu-nc-kernel-6_6, sys-kernel/lakitu-vgpu-kernel-6_6, sys-kernel/tpusev-kernel-6_6: security update to 18613.675.2

high Tenable Self-Hosted Container Security Plugin ID 465997

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: af_unix: Fix UAF read of tail->len in
unix_stream_data_wait() unix_stream_data_wait() does skb_peek_tail(&sk->sk_receive_queue) without holding
any lock that prevents SKBs on that queue from being dequeued and freed. This has been the case since
commit 79f632c71bea ("unix/stream: fix peeking with an offset larger than data in queue"). The first
consequence of this is that the pointer comparison `tail != last` can be false even if `last` semantically
refers to an already-freed SKB while `tail` is a new SKB allocated at the same address; which can cause
unix_stream_data_wait() to wrongly keep blocking after new data has arrived, but only in a weird scenario
where a peeking recv() and a normal recv() on the same socket are racing, which is probably not a real
problem. But since commit 2b514574f7e8 ("net: af_unix: implement splice for stream af_unix sockets"),
`tail` is actually dereferenced, which can cause UAF in the following race scenario (where test_setup()
runs single-threaded, and afterwards, test_thread1() and test_thread2() run concurrently in two threads:
``` static int socks[2]; void test_setup(void) { socketpair(AF_UNIX, SOCK_STREAM, 0, socks);
send(socks[1], "A", 1, 0); int peekoff = 1; setsockopt(socks[0], SOL_SOCKET, SO_PEEK_OFF, &peekoff,
sizeof(peekoff)); } void test_thread1(void) { char dummy; recv(socks[0], &dummy, 1, MSG_PEEK); } void
test_thread2(void) { char dummy; recv(socks[0], &dummy, 1, 0); shutdown(socks[1], SHUT_WR); } ``` when
racing like this: ``` thread1 thread2 unix_stream_read_generic mutex_lock(&u->iolock)
skb_peek(&sk->sk_receive_queue) skb_peek_next(skb, &sk->sk_receive_queue) mutex_unlock(&u->iolock)
unix_stream_read_generic unix_state_lock(sk) skb_peek(&sk->sk_receive_queue) unix_state_unlock(sk)
unix_stream_data_wait unix_state_lock(sk) tail = skb_peek_tail(&sk->sk_receive_queue)
spin_lock(&sk->sk_receive_queue.lock) __skb_unlink(skb, &sk->sk_receive_queue)
spin_unlock(&sk->sk_receive_queue.lock) consume_skb(skb) [frees the SKB] `tail != last`: false `tail`:
true `tail->len != last_len` ***UAF*** ``` Fix the UAF by removing the read of tail->len; checking
tail->len would only make sense if SKBs in the receive queue of a UNIX socket could grow, which can no
longer happen. Kuniyuki explained: > When commit 869e7c62486e ("net: af_unix: implement stream sendpage >
support") added sendpage() support, data could be appended to the last > skb in the receiver's queue. > >
That's why we needed to check if the length of the last skb was changed > while waiting for new data in
unix_stream_data_wait(). > > However, commit a0dbf5f818f9 ("af_unix: Support MSG_SPLICE_PAGES") and >
commit 57d44a354a43 ("unix: Convert unix_stream_sendpage() to use > MSG_SPLICE_PAGES") refactored
sendmsg(), and now data is always added > to a new skb. That means this fix is not suitable for kernels
before 6.5. (CVE-2026-64109)

Solution

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

Plugin Details

Severity: High

ID: 465997

Version: Revision 1.2

Type: Local

Family: Google COS Security Checks

Published: 10/2/2026

Updated: 10/3/2026

Risk Information

VPR

Risk Factor: High

Score: 7.8

Percentile: 99.33

Vendor

Vendor Severity: HIGH

CVSS v2

Risk Factor: Medium

Base Score: 6.8

Temporal Score: 5

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

CVSS Score Source: CVE-2026-64109

CVSS v3

Risk Factor: High

Base Score: 8.8

Temporal Score: 7.7

Vector: CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:C/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/4/2026

Reference Information

CVE: CVE-2026-64109

Detections

Analytics