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

high Tenable Self-Hosted Container Security Plugin ID 469749

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: bpf, x86: Fix per-CPU address
resolution into an extended register The destination of the per-CPU address MOV is encoded in ModRM.reg,
which is extended by REX.R, but the REX prefix is built with add_1mod(), which sets REX.B. REX.B extends
ModRM.rm and SIB.base, and this instruction addresses memory as disp32 with no base, so the bit has no
effect at all and the high register bit is simply lost. Every is_ereg() destination therefore resolves to
the wrong register, picking whichever one shares the low three bits: R5 -> RAX R7 -> RBP R8 -> RSI R9 ->
RDI With BPF_REG_5, whose reg2hex is 0, the emitted 65 49 03 04 25 <off> add %gs:<off>,%rax adds the per-
CPU offset to RAX rather than R8. The destination keeps the unadjusted address and RAX is clobbered, so
the program goes on to dereference a pointer that was never made per-CPU: BUG: unable to handle page fault
for address: 0000607e386a8894 RIP: bpf_prog_707837aafd2aa9ae_update_percpu_data+0x93/0xc9 Call Trace:
__bpf_prog_test_run_raw_tp+0x2dc/0x7d0 __flush_smp_call_function_queue+0x1e9/0xc80 Kernel panic - not
syncing: Fatal exception in interrupt R5 is the mildest of the four, aliasing a scratch register and
faulting at the store. R7 aliases RBP and would corrupt the frame pointer, R8 and R9 alias the argument
registers. Use add_2mod() so the register goes through REX.R, matching how add_2reg() places it in
ModRM.reg and how emit_priv_frame_ptr() hardcodes 0x4c for the same instruction with R9. Encodings for the
non-extended registers are unchanged. Problem showed up when trying to resurrect BPF_GCC CI (selftests
built with BPF_GCC). This has gone unnoticed because clang reloads the address into R1 before each per-CPU
access, so the destination is never an extended register. GCC keeps several per-CPU addresses live at
once, and test_progs-bpf_gcc panics the kernel in global_percpu_data/init, where the address of a .percpu
variable ends up in R5. (CVE-2026-89581)

Solution

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

Plugin Details

Severity: High

ID: 469749

Version: Revision 1.3

Type: Local

Family: Google COS Security Checks

Published: 10/3/2026

Updated: 10/3/2026

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

Risk Information

VPR

Risk Factor: Medium

Score: 4.9

Percentile: 58.22

Vendor

Vendor Severity: LOW

CVSS v2

Risk Factor: Medium

Base Score: 6.8

Temporal Score: 5

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

CVSS Score Source: CVE-2026-89581

CVSS v3

Risk Factor: High

Base Score: 7.8

Temporal Score: 6.8

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: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-89581

Detections

Analytics