Google: sys-kernel/cchost-kernel-6_18, sys-kernel/csql-kernel-6_18, sys-kernel/lakitu-kernel-6_18, sys-kernel/lakitu-nc-kernel-6_18: security update to 20085.0.0

high Tenable Self-Hosted Container Security Plugin ID 471568

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: ublk: wait on ublk_dev_ready() instead
of ub->completion ub->completion is only re-armed by a successful START_USER_RECOVERY. If the ublk server
sends END_USER_RECOVERY without one - e.g. its START failed with -EBUSY and the error was ignored - the
wait is satisfied by the stale completion of the previous recovery cycle, and the device is marked LIVE
and the requeue list kicked while the FETCH stream is still running and ubq->canceling is still set. The
kick redispatches a previously requeued request, __ublk_queue_rq_common() sees ->canceling and parks it
again via __ublk_abort_rq(), and after the last FETCH clears ->canceling nothing ever kicks the requeue
list again: the request is stranded there while holding its tag. If it is the flush machinery's flush_rq,
every subsequent fsync piles up in uninterruptible sleep and teardown hangs on tag draining. This matches
a report of a lost PREFLUSH with ext4 on top of ublk after daemon crash recovery. ub->completion is an
edge-triggered latch used as a proxy for the level condition "every queue has fetched all I/O commands",
which can regress (F_BATCH's UNPREP, daemon death) and whose re-arm can be skipped. Drop it and wait on
the real condition instead: the new helper ublk_wait_dev_ready_and_lock() waits on ublk_dev_ready() via
wait_var_event_interruptible(), woken from ublk_mark_io_ready(), then re-checks it under ub->mutex,
waiting again on regression, and returns with the mutex held and readiness guaranteed. Readiness becomes
true in the same ub->mutex critical section that clears the last queue's ->canceling, so END_USER_RECOVERY
marks the device LIVE and kicks the requeue list strictly after ->canceling clears. The wait stays
interruptible, so a server whose daemon died can still be signalled out. For ublk_ctrl_start_dev() this
replaces the fail-fast -EINVAL on an F_BATCH ready->UNPREP regression with waiting until the device is
ready again. (CVE-2026-68173)

Solution

Update the sys-kernel/cchost-kernel-6_18 library and its related packages to version 20085.0.0 or later.

Plugin Details

Severity: High

ID: 471568

Version: Revision 1.4

Type: Local

Family: Google COS Security Checks

Published: 10/3/2026

Updated: 10/6/2026

Supported Sensors: Tenable Cloud Security, Tenable Self-Hosted Container Security

Risk Information

VPR

Risk Factor: Medium

Score: 4.3

Percentile: 53.58

Vendor

Vendor Severity: LOW

CVSS v2

Risk Factor: Medium

Base Score: 6.2

Temporal Score: 4.6

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

CVSS Score Source: CVE-2026-68173

CVSS v3

Risk Factor: High

Base Score: 7.1

Temporal Score: 6.2

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

Reference Information

CVE: CVE-2026-68173

Detections

Analytics