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

high Tenable Self-Hosted Container Security Plugin ID 468653

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: eventpoll: fix ep_remove struct
eventpoll / struct file UAF ep_remove() (via ep_remove_file()) cleared file->f_ep under file->f_lock but
then kept using @file inside the critical section (is_file_epoll(), hlist_del_rcu() through the head,
spin_unlock). A concurrent __fput() taking the eventpoll_release() fastpath in that window observed the
transient NULL, skipped eventpoll_release_file() and ran to f_op->release / file_free(). For the epoll-
watches-epoll case, f_op->release is ep_eventpoll_release() -> ep_clear_and_put() -> ep_free(), which
kfree()s the watched struct eventpoll. Its embedded ->refs hlist_head is exactly where epi->fllink.pprev
points, so the subsequent hlist_del_rcu()'s "*pprev = next" scribbles into freed kmalloc-192 memory. In
addition, struct file is SLAB_TYPESAFE_BY_RCU, so the slot backing @file could be recycled by
alloc_empty_file() -- reinitializing f_lock and f_ep -- while ep_remove() is still nominally inside that
lock. The upshot is an attacker-controllable kmem_cache_free() against the wrong slab cache. Pin @file via
epi_fget() at the top of ep_remove() and gate the critical section on the pin succeeding. With the pin
held @file cannot reach refcount zero, which holds __fput() off and transitively keeps the watched struct
eventpoll alive across the hlist_del_rcu() and the f_lock use, closing both UAFs. If the pin fails @file
has already reached refcount zero and its __fput() is in flight. Because we bailed before clearing f_ep,
that path takes the eventpoll_release() slow path into eventpoll_release_file() and blocks on ep->mtx
until the waiter side's ep_clear_and_put() drops it. The bailed epi's share of ep->refcount stays intact,
so the trailing ep_refcount_dec_and_test() in ep_clear_and_put() cannot free the eventpoll out from under
eventpoll_release_file(); the orphaned epi is then cleaned up there. A successful pin also proves we are
not racing eventpoll_release_file() on this epi, so drop the now-redundant re-check of epi->dying under
f_lock. The cheap lockless READ_ONCE(epi->dying) fast-path bailout stays. (CVE-2026-46242)

Solution

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

Plugin Details

Severity: High

ID: 468653

Version: Revision 1.5

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

Percentile: 99.36

Vendor

Vendor Severity: LOW

CVSS v2

Risk Factor: Medium

Base Score: 6.8

Temporal Score: 5.3

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

CVSS Score Source: CVE-2026-46242

CVSS v3

Risk Factor: High

Base Score: 7.8

Temporal Score: 7

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:P/RL:O/RC:C

Vulnerability Information

Exploit Available: true

Exploit Ease: Exploits are available

Vulnerability Publication Date: 5/30/2026

Reference Information

CVE: CVE-2026-46242

Detections

Analytics