Google: sys-kernel/cchost-kernel-6_12, sys-kernel/csql-kernel-6_12, sys-kernel/lakitu-kernel-6_12, sys-kernel/lakitu-nc-kernel-6_12: security update to 19506.299.82

critical Tenable Self-Hosted Container Security Plugin ID 469703

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: nvmet: fix pre-auth out-of-bounds heap
read in Discovery Get Log Page nvmet_execute_disc_get_log_page() validates only the dword alignment of the
host-supplied Log Page Offset (lpo). The 64-bit offset is then added to a small kzalloc'd buffer that
holds the discovery log page and the result is passed straight to nvmet_copy_to_sgl(), which memcpy()s
data_len bytes out to the host with no source-side bound check: u64 offset =
nvmet_get_log_page_offset(req->cmd); /* 64-bit host */ size_t data_len = nvmet_get_log_page_len(req->cmd);
/* 32-bit host */ ... if (offset & 0x3) { ... } /* only check */ ... alloc_len = sizeof(*hdr) + entry_size
* discovery_log_entries(req); buffer = kzalloc(alloc_len, GFP_KERNEL); ... status = nvmet_copy_to_sgl(req,
0, buffer + offset, data_len); The Discovery controller is unauthenticated -- nvmet_host_allowed() returns
true unconditionally for the discovery subsystem -- so the call is reachable pre-authentication by any
TCP/RDMA/FC peer that can reach the nvmet target. With a discovery log page of ~1 KiB, an attacker
requesting up to 4 KiB starting at offset == alloc_len reads the next slab page out and gets its content
returned over the fabric (an empirical run on a default nvmet-tcp loopback target leaked 81 canonical
kernel pointers in one Get Log Page response). Pointing the offset at unmapped kernel memory faults the
in-kernel memcpy and crashes (or panics, on panic_on_oops=1) the target host instead. The attacker-
controlled source-side offset pattern "nvmet_copy_to_sgl(req, 0, buffer + ATTACKER_OFFSET, ...)" is unique
to nvmet_execute_disc_get_log_page in the entire nvmet codebase: every other Get Log Page handler in
admin-cmd.c either ignores lpo (and silently starts every response at offset 0) or tracks a local
destination offset with a fixed source pointer. Validate the host-supplied offset against the log page
size, cap the copy length to what is actually available, and zero-fill any remainder of the host transfer
buffer. The zero-fill matches the existing short-response pattern in nvmet_execute_get_log_changed_ns()
(admin-cmd.c) and prevents leaking transport SGL contents when the host asks for more bytes than the log
page contains. (CVE-2026-64320)

Solution

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

Plugin Details

Severity: Critical

ID: 469703

Version: Revision 1.5

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.44

Vendor

Vendor Severity: HIGH

CVSS v2

Risk Factor: High

Base Score: 9.4

Temporal Score: 7

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

CVSS Score Source: CVE-2026-64320

CVSS v3

Risk Factor: Critical

Base Score: 9.1

Temporal Score: 7.9

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

Reference Information

CVE: CVE-2026-64320

Detections

Analytics