Detections
Analytics

Google: sys-kernel/csql-kernel-6_1, sys-kernel/lakitu-kernel-6_1: security update to 18244.85.5

medium Tenable Cloud Security Plugin ID 451431

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: Clear stale u->oob_skb.
 syzkaller started to report deadlock of unix_gc_lock after commit 4090fa373f0e ("af_unix: Replace garbage
 collection algorithm."), but it just uncovers the bug that has been there since commit 314001f0bf92
 ("af_unix: Add OOB support"). The repro basically does the following. from socket import * from array
 import array c1, c2 = socketpair(AF_UNIX, SOCK_STREAM) c1.sendmsg([b'a'], [(SOL_SOCKET, SCM_RIGHTS,
 array("i", [c2.fileno()]))], MSG_OOB) c2.recv(1) # blocked as no normal data in recv queue c2.close() #
 done async and unblock recv() c1.close() # done async and trigger GC A socket sends its file descriptor to
 itself as OOB data and tries to receive normal data, but finally recv() fails due to async close(). The
 problem here is wrong handling of OOB skb in manage_oob(). When recvmsg() is called without MSG_OOB,
 manage_oob() is called to check if the peeked skb is OOB skb. In such a case, manage_oob() pops it out of
 the receive queue but does not clear unix_sock(sk)->oob_skb. This is wrong in terms of uAPI. Let's say we
 send "hello" with MSG_OOB, and "world" without MSG_OOB. The 'o' is handled as OOB data. When recv() is
 called twice without MSG_OOB, the OOB data should be lost. >>> from socket import * >>> c1, c2 =
 socketpair(AF_UNIX, SOCK_STREAM, 0) >>> c1.send(b'hello', MSG_OOB) # 'o' is OOB data 5 >>>
 c1.send(b'world') 5 >>> c2.recv(5) # OOB data is not received b'hell' >>> c2.recv(5) # OOB date is skipped
 b'world' >>> c2.recv(5, MSG_OOB) # This should return an error b'o' In the same situation, TCP actually
 returns -EINVAL for the last recv(). Also, if we do not clear unix_sk(sk)->oob_skb, unix_poll() always set
 EPOLLPRI even though the data has passed through by previous recv(). To avoid these issues, we must clear
 unix_sk(sk)->oob_skb when dequeuing it from recv queue. The reason why the old GC did not trigger the
 deadlock is because the old GC relied on the receive queue to detect the loop. When it is triggered, the
 socket with OOB data is marked as GC candidate because file refcount == inflight count (1). However, after
 traversing all inflight sockets, the socket still has a positive inflight count (1), thus the socket is
 excluded from candidates. Then, the old GC lose the chance to garbage-collect the socket. With the old GC,
 the repro continues to create true garbage that will never be freed nor detected by kmemleak as it's
 linked to the global inflight list. That's why we couldn't even notice the issue. (CVE-2024-35970)

Solution

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

See Also

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

Plugin Details

Severity: Medium

ID: 451431

Version: Revision 1.1

Type: Local

Published: 10/1/2026

Updated: 10/1/2026

Risk Information

VPR

Risk Factor: Medium

Score: 4.8

Percentile: 56.93

Vendor

Vendor Severity: MEDIUM

CVSS v2

Risk Factor: Medium

Base Score: 6.5

Temporal Score: 4.8

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

CVSS Score Source: CVE-2024-35970

CVSS v3

Risk Factor: Medium

Base Score: 6.3

Temporal Score: 5.5

Vector: CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L

Temporal Vector: CVSS:3.0/E:U/RL:O/RC:C

Vulnerability Information

Exploit Ease: No known exploits are available

Vulnerability Publication Date: 5/13/2024

Reference Information

CVE: CVE-2024-35970