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

high Tenable Self-Hosted Container Security Plugin ID 475424

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: perf: Fix use-after-free when perf
mmap() revival races with the last munmap() perf_mmap_close() drops rb->mmap_count *without* holding
event->mmap_mutex (the refcount_dec_and_test() right before the refcount_dec_and_mutex_lock() of
event->mmap_count). A concurrent perf_mmap_rb() can slot its entire "revival" path into that window
(perf_mmap holds event->mmap_mutex for its whole duration, including rb_alloc): munmap side
(perf_mmap_close) mmap side (perf_mmap_rb) -----------------------------------
-------------------------------- rb->mmap_count 1 -> 0 (no lock) (holds event->mmap_mutex)
inc_not_zero(rb->mmap_count) fails ring_buffer_attach(event, NULL) rb_alloc() + attach new rb
refcount_set(&event->mmap_count, 1) lock; event->mmap_count 1 -> 0 ring_buffer_attach(event, NULL)
ring_buffer_put() -> frees the *new* rb The revival's refcount_set(&event->mmap_count, 1) is an invisible
1 -> 1 write: the close frees the just-revived buffer although the other process still has it mapped -- a
page-level use-after-free allowing local privilege escalation to root by any unprivileged user (default
kernel.perf_event_paranoid=2). Swap the order of the two counter updates: event->mmap_count is dropped
first via refcount_dec_and_mutex_lock(), so its 1 -> 0 transition and the ring_buffer_attach() stay
serialized with perf_mmap(). rb->mmap_count == 0 then implies every event using the buffer is detached
already, so the result of the rb->mmap_count drop can gate the remaining teardown directly and detach_rest
is no longer needed. An earlier fix for this race from Kyle Zeng and David Lee takes event->mmap_mutex
around both counter updates [0]; here the not-last close stays lockless. (CVE-2026-89791)

Solution

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

See Also

https://storage.googleapis.com/cos-oval-vulnerability-feed/cos-133.oval.xml.tar.gz

Plugin Details

Severity: High

ID: 475424

Version: Revision 1.1

Type: Local

Published: 10/16/2026

Updated: 10/16/2026

Risk Information

VPR

Risk Factor: Medium

Score: 4.9

Percentile: 58.41

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

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/16/2026

Reference Information

CVE: CVE-2026-89791