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

critical Tenable Cloud Security Plugin ID 475522

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: nvme-tcp: do not accept C2HData based
on blk_rq_payload_bytes() alone Commit 25e5cb780e62 ("nvme-tcp: fix possible crash in write_zeroes
processing") established that blk_rq_payload_bytes() must not be read without first checking
blk_rq_nr_phys_segments(), and recorded the result in nvme_tcp_setup_cmd_pdu() as req->data_len. The
receive side was left as it was. The two differ for REQ_OP_WRITE_ZEROES, which has no physical segments
but a non-zero blk_rq_bytes(), so setup leaves req->iter untouched while the receive gate lets a C2HData
through and nvme_tcp_recv_data() copies into whatever the previous command on that tag left there. The
driver-private area is zeroed only when the tag set is allocated. Reproduced with a test target that
leaves a residual iterator on a tag and then sends a C2HData for a WRITE_ZEROES command on the same tag:
BUG: KASAN: wild-memory-access in _copy_to_iter+0x642/0x1330 Write of size 512 at addr ffe728c2175dfa81 by
task kworker/0:1H/103 CPU: 0 UID: 0 PID: 103 Comm: kworker/0:1H Not tainted 7.2.0-rc5-NVMETCP-
gf5098b6bae76 #1 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix,
1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: nvme_tcp_wq nvme_tcp_io_work Call Trace: <TASK>
dump_stack_lvl+0x53/0x70 kasan_report+0xce/0x100 ? _copy_to_iter+0x642/0x1330
kasan_check_range+0x105/0x1b0 __asan_memcpy+0x3c/0x60 _copy_to_iter+0x642/0x1330 ?
__pfx_sock_has_perm+0x10/0x10 ? worker_thread+0x45b/0xd10 ? __pfx__copy_to_iter+0x10/0x10 ?
_raw_spin_lock_bh+0x83/0xe0 ? __pfx__raw_spin_lock_bh+0x10/0x10 __skb_datagram_iter+0xf3/0x820 ?
__pfx_simple_copy_to_iter+0x10/0x10 ? __asan_memcpy+0x3c/0x60 ? skb_copy_bits+0x58d/0x830
skb_copy_datagram_iter+0x37/0x120 nvme_tcp_recv_skb+0xa07/0x4320 ? __pfx_nvme_tcp_recv_skb+0x10/0x10
__tcp_read_sock+0x1ab/0x810 ? __pfx_nvme_tcp_recv_skb+0x10/0x10 ? __pfx_lock_sock_nested+0x10/0x10 ?
__pfx___tcp_read_sock+0x10/0x10 nvme_tcp_try_recv+0x152/0x1e0 ? __pfx_nvme_tcp_try_recv+0x10/0x10 ?
__pfx_mutex_unlock+0x10/0x10 nvme_tcp_io_work+0x1e4/0x6c0 ? __schedule+0x181a/0x49f0 ?
__pfx_nvme_tcp_io_work+0x10/0x10 process_one_work+0x633/0x1030 Keep the blk_rq_payload_bytes() test and
add req->data_len to it. The old test is what rejects a C2HData naming a tag that is no longer in flight,
because blk_update_request() zeroes rq->__data_len on completion; req->data_len and req->curr_bio are
driver-private and survive completion, so they cannot stand in for it. Setup initialises the iterator only
when both req->curr_bio and req->data_len are set, so the gate now tests the same two. (CVE-2026-89482)

Solution

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

Plugin Details

Severity: Critical

ID: 475522

Version: Revision 1.1

Type: Local

Family: Google COS Security Checks

Published: 10/16/2026

Updated: 10/16/2026

Risk Information

VPR

Risk Factor: High

Score: 7.6

Percentile: 98.26

Vendor

Vendor Severity: LOW

CVSS v2

Risk Factor: Critical

Base Score: 10

Temporal Score: 7.4

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

CVSS Score Source: CVE-2026-89482

CVSS v3

Risk Factor: Critical

Base Score: 9.8

Temporal Score: 8.5

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

Reference Information

CVE: CVE-2026-89482

Detections

Analytics