Detections
Analytics

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

medium Tenable Cloud Security Plugin ID 472179

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/9p: fix infinite loop in
 p9_client_rpc on fatal signal When p9_client_rpc() is called with type P9_TFLUSH and the transport has no
 peer (e.g. fd transport backed by pipes with no 9p server), a fatal signal causes an infinite loop: again:
 err = io_wait_event_killable(req->wq, ...) /* SIGKILL wakes the task, returns -ERESTARTSYS */ if (err ==
 -ERESTARTSYS && c->status == Connected && type == P9_TFLUSH) { sigpending = 1;
 clear_thread_flag(TIF_SIGPENDING); goto again; } clear_thread_flag() clears TIF_SIGPENDING before jumping
 back to io_wait_event_killable(). signal_pending_state() checks TIF_SIGPENDING, finds it zero, and the
 task goes to sleep again. The task can only wake on the next signal delivery that calls signal_wake_up()
 and sets TIF_SIGPENDING again. When that happens the loop repeats, clears TIF_SIGPENDING, and sleeps again
 indefinitely. This is triggered in practice by coredump_wait(): when a thread in a multi-threaded process
 causes a coredump (e.g. via SIGSYS from Syscall User Dispatch), coredump_wait() sends SIGKILL to all other
 threads and waits for them to call mm_release(). If one of those threads is blocked in p9_client_rpc()
 over an fd transport with no peer, it enters the P9_TFLUSH loop and never calls mm_release(), so
 coredump_wait() stalls forever: INFO: task syz.0.18:676 blocked for more than 143 seconds. Not tainted
 6.12.77+ #1 task:syz.0.18 state:D stack:27600 pid:676 tgid:673 ppid:630 flags:0x00000004 Call Trace:
 <TASK> context_switch kernel/sched/core.c:5344 [inline] __schedule+0xcb4/0x5d50 kernel/sched/core.c:6724
 __schedule_loop kernel/sched/core.c:6801 [inline] schedule+0xe5/0x350 kernel/sched/core.c:6816
 schedule_timeout+0x253/0x290 kernel/time/timer.c:2593 do_wait_for_common kernel/sched/completion.c:95
 [inline] __wait_for_common+0x409/0x600 kernel/sched/completion.c:116 wait_for_common
 kernel/sched/completion.c:127 [inline] wait_for_completion_state+0x1d/0x40 kernel/sched/completion.c:264
 coredump_wait fs/coredump.c:448 [inline] do_coredump+0x854/0x4350 fs/coredump.c:629
 get_signal+0x1425/0x2730 kernel/signal.c:2903 arch_do_signal_or_restart+0x81/0x880
 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop kernel/entry/common.c:111 [inline]
 exit_to_user_mode_prepare include/linux/entry-common.h:328 [inline] __syscall_exit_to_user_mode_work
 kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0xf9/0x160 kernel/entry/common.c:218
 do_syscall_64+0x102/0x220 arch/x86/entry/common.c:84 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> Fix:
 check fatal_signal_pending() before clearing TIF_SIGPENDING in the P9_TFLUSH retry loop. At that point
 TIF_SIGPENDING is still set, so fatal_signal_pending() works correctly. If a fatal signal is pending, jump
 to recalc_sigpending to restore TIF_SIGPENDING and return -ERESTARTSYS to the caller. The same defect is
 present in stable kernels back to 5.4. On those kernels the infinite loop is broken earlier by a second
 SIGKILL from the parent process (e.g. kill_and_wait() retrying after a timeout), resulting in a zombie
 process and a shutdown delay rather than a permanent D-state hang, but the underlying flaw is the same.
 Found by Linux Verification Center (linuxtesting.org) with Syzkaller. (CVE-2026-72166)

Solution

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

See Also

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

Plugin Details

Severity: Medium

ID: 472179

Version: Revision 1.2

Type: Local

Published: 10/3/2026

Updated: 10/3/2026

Risk Information

VPR

Risk Factor: Medium

Score: 5

Percentile: 93.48

Vendor

Vendor Severity: LOW

CVSS v2

Risk Factor: Medium

Base Score: 4.9

Temporal Score: 3.6

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

CVSS Score Source: CVE-2026-72166

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: 8/11/2026

Reference Information

CVE: CVE-2026-72166