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

high Tenable Self-Hosted Container Security Plugin ID 469280

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: btrfs: reject free space cache with
more entries than pages When loading a v1 free space cache, __load_free_space_cache() takes num_entries
and num_bitmaps straight from the on-disk btrfs_free_space_header. That header is stored in the tree_root
under a key with type 0, which the tree-checker has no case for, so neither count is validated before the
load trusts it. The load loops num_entries times and maps the next page whenever the current one runs out,
going through io_ctl_check_crc() -> io_ctl_map_page(), which does io_ctl->pages[io_ctl->index++]. But
pages[] is allocated in io_ctl_init() from the cache inode's i_size, not from num_entries: num_pages =
DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE); io_ctl->pages = kcalloc(num_pages, sizeof(struct page *),
GFP_NOFS); So if num_entries claims more records than the pages can hold, io_ctl->index runs off the end
of pages[]. The write side never hits this because io_ctl_add_entry() and io_ctl_add_bitmap() both stop
once io_ctl->index >= io_ctl->num_pages; the read side just never had the same check. To trigger it, take
a clean cache (num_entries = <N> here), set num_entries in the header to 0x10000, and fix up the leaf
checksum so it still passes the tree-checker. The cache inode has i_size = 65536, so num_pages is 16 and
pages[] is a 16-pointer (kmalloc-128) array. The load now tries to read 65536 entries, io_ctl->index walks
up to 16, and pages[16] is read past the array: BUG: KASAN: slab-out-of-bounds in io_ctl_check_crc
(fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) Read of size 8 at addr ffff88800c833a80
by task kworker/u8:3/58 io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565)
__load_free_space_cache (fs/btrfs/free-space-cache.c:655 fs/btrfs/free-space-cache.c:820)
load_free_space_cache (fs/btrfs/free-space-cache.c:1017) caching_thread (fs/btrfs/block-group.c:880)
btrfs_work_helper (fs/btrfs/async-thread.c:312) process_one_work worker_thread kthread ret_from_fork free-
space-cache.c:420 is io_ctl_map_page(), inlined into io_ctl_check_crc() at line 565, which is why that is
the frame KASAN names. The out-of-bounds slot is then treated as a struct page and handed to crc32c(), so
the bad read turns into a GP fault. Add the missing check to io_ctl_check_crc(), which is where both the
entry loop and the bitmap loop end up. When num_entries is too large the load now fails like any corrupt
cache: __load_free_space_cache() drops it and rebuilds the free space from the extent tree, so a valid
cache is never rejected. (CVE-2026-64567)

Solution

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

Plugin Details

Severity: High

ID: 469280

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

Score: 6.9

Percentile: 96.56

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

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: 8/5/2026

Reference Information

CVE: CVE-2026-64567

Detections

Analytics