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

high Tenable Self-Hosted Container Security Plugin ID 468943

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: KVM: x86/mmu: Ensure hugepage is in by
slot before checking max mapping level When recovering hugepages in the shadow MMU, verify that the base
gfn of the shadow page is actually contained within the target memslot, *before* querying the max mapping
level given the shadow page's gfn. Failure to pre-check the validity of the gfn can lead to an out-of-
bounds access to the slot's lpage_info (which typically manifests as a host #PF because the lpage_info is
vmalloc'd) if the guest creates a hugepage mapping (in its PTEs) that extends "below" the bounds of a
memslot. When faulting in memory for a guest, and the size of the guest mapping is greater than KVM's
(current) max mapping, then KVM will create a "direct" shadow page (direct in that there are no gPTEs to
shadow, and so the target gfn is a direct calculation given the base gfn of the shadow page). The hugepage
recovery flow looks for such direct shadow pages, as forcing 4KiB mappings when dirty logging generates
the guest > host mapping size case. When the 4KiB restriction is lifted, then KVM can replace the shadow
page with a hugepage. But if KVM originally used a smaller mapping than the guest because the range of
memory covered by the guest hugepage exceeds the bounds of a memslot, then KVM will link a direct shadow
page with a gfn that is outside the bounds of the memslot being used to fault in memory. The rmap entry
added for the leaf mapping is correct and within bounds, but the gfn of the leaf SPTE's parent shadow page
will be out of bounds. BUG: unable to handle page fault for address: ffffc90000806ffc #PF: supervisor read
access in kernel mode #PF: error_code(0x0000) - not-present page PGD 100000067 P4D 100000067 PUD 1002a7067
PMD 10612f067 PTE 0 Oops: Oops: 0000 [#1] SMP CPU: 13 UID: 1000 PID: 757 Comm: mmu_stress_test Not tainted
7.1.0-rc1-48ce1e26eace-x86_pir_to_irr_comments-vm #341 PREEMPT Hardware name: QEMU Standard PC (Q35 +
ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:kvm_mmu_max_mapping_level+0x79/0x2b0 [kvm] Call Trace: <TASK>
kvm_mmu_recover_huge_pages+0x21b/0x320 [kvm] kvm_set_memslot+0x1ee/0x590 [kvm]
kvm_set_memory_region.part.0+0x3a1/0x4d0 [kvm] kvm_vm_ioctl+0x9bf/0x15d0 [kvm] __x64_sys_ioctl+0x8a/0xd0
do_syscall_64+0xb7/0xbb0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f21c0f1a9bf </TASK> Don't
bother pre-checking the bounds of the potential hugepage, i.e. don't check that e.g. sp->gfn +
KVM_PAGES_PER_HPAGE(sp->role.level + 1) is also within the memslot, as the checks performed by
kvm_mmu_max_mapping_level() are a superset of the basic bounds checks. I.e. pre-checking the full range
would be a dubious micro-optimization. (CVE-2026-63807)

Solution

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

Plugin Details

Severity: High

ID: 468943

Version: Revision 1.6

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

Score: 7

Percentile: 98.21

Vendor

Vendor Severity: HIGH

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-63807

CVSS v3

Risk Factor: High

Base Score: 8.8

Temporal Score: 7.7

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

Reference Information

CVE: CVE-2026-63807

Detections

Analytics