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

high Tenable Cloud Security Plugin ID 466817

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: posix-cpu-timers: Prevent UAF caused
by non-leader exec() race Wongi and Jungwoo decoded and reported a non-leader exec() related race which
can result in an UAF: sys_timer_delete() exec() posix_cpu_timer_del() // Observes old leader p =
pid_task(pid, pid_type); de_thread() switch_leader(); release_task(old_leader) __exit_signal(old_leader)
sighand = lock(old_leader, sighand); posix_cpu_timers*_exit(); sighand = lock_task_sighand(p)
unhash_task(old_leader); sh = lock(p, sighand) old_leader->sighand = NULL; unlock(sighand); (p->sighand ==
NULL) unlock(sh) return NULL; // Returns without action if(!sighand) return 0; free_posix_timer(); This is
"harmless" unless the deleted timer was armed and enqueued in p->signal because on exec() a TGID targeted
timer is inherited. As sys_timer_delete() freed the underlying posix timer object run_posix_cpu_timers()
or any timerqueue related add/delete operations on other timers will access the freed object's timerqueue
node, which results in an UAF. There is a similar problem vs. posix_cpu_timer_set(). For regular posix
timers it just transiently returns -ESRCH to user space, but for the use case in do_cpu_nanosleep() it's
the same UAF just that the k_itimer is allocated on the stack. Also posix_cpu_timer_rearm() fails to rearm
the timer, which means it stops to expire. While debating solutions Frederic pointed out another problem:
posix_cpu_timer_del(tmr) __exit_signal(p) posix_cpu_timers*_exit(p); unhash_task(p); p->sighand = NULL; sh
= lock_task_sighand(p) sighand = p->sighand; if (!sighand) return NULL; lock(sighand); if (!sh)
WARN_ON_ONCE(timer_queued(tmr)); On weakly ordered architectures it is not guaranteed that
posix_cpu_timer_del() will observe the stores in posix_cpu_timers*_exit() when p->sighand is observed as
NULL, which means the WARN() can be a false positive. Solve these issues by: 1) Changing the store in
__exit_signal() to smp_store_release(). 2) Adding a smp_acquire__after_ctrl_dep() into the !sighand path
of lock_task_sighand(). 3) Creating a helper function for looking up the task and locking sighand which
does not return when sighand == NULL. Instead it retries the task lookup and only if that fails it gives
up. 4) Using that helper in the three affected functions. #1/#2 ensures that the reader side which
observes sighand == NULL also observes all preceeding stores, i.e. the stores in posix_cpu_timers*_exit()
and the ones in unhash_task(). #3 ensures that the above described non-leader exec() situation is handled
gracefully. When the task lookup returns the old leader, but sighand == NULL then it retries. In the non-
leader exec() case the subsequent task lookup will observe the new leader due to #1/#2. In normal exit()
scenarios the subsequent lookup fails. When the task lookup fails, the function also checks whether the
timer is still enqueued and issues a warning if that's the case. Unfortunately there is nothing which can
be done about it, but as the task is already not longer visible the timer should not be accessed anymore.
This check also requires memory ordering, which is not provided when the first lookup fails. To achieve
that the check is preceeded by a smp_rmb() which pairs with the smp_wmb() in write_seqlock() in
__exit_signal(). That ensures that the stores in posix_cpu_timers*_exit() are visible. The history of the
non-leader exec() issue goes back to the early days of posix CPU timers, which stored a pointer to the
group leader task in the timer. That obviously fails when a non-leader exec() switches the leader. commit
e0a70217107e ("posix-cpu-timers: workaround to suppress the problems with mt exec") added a temporary
workaround for that in 2010 which surv ---truncated--- (CVE-2026-64560)

Solution

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

Plugin Details

Severity: High

ID: 466817

Version: Revision 1.1

Type: Local

Family: Google COS Security Checks

Published: 10/2/2026

Updated: 10/2/2026

Risk Information

VPR

Risk Factor: High

Score: 7.7

Percentile: 99

Vendor

Vendor Severity: LOW

CVSS v2

Risk Factor: Medium

Base Score: 6.8

Temporal Score: 5.3

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

CVSS Score Source: CVE-2026-64560

CVSS v3

Risk Factor: High

Base Score: 7.8

Temporal Score: 7

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

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

Vulnerability Information

Exploit Available: true

Exploit Ease: Exploits are available

Vulnerability Publication Date: 7/29/2026

Reference Information

CVE: CVE-2026-64560

Detections

Analytics