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 20085.0.0

high Tenable Self-Hosted Container Security Plugin ID 471375

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: mm/slab: prevent unbounded recursion
in free path with new kmalloc type Commit 280ea9c3154b ("mm/slab: avoid allocating slabobj_ext array from
its own slab") avoided recursive allocation of obj_exts from kmalloc caches of the same size, by bumping
the obj_exts array's allocation size whenever the array size equals the size of the object being
allocated. However, as reported by Danielle Costantino and Shakeel Butt, even slabs from kmalloc caches of
different sizes can form a cycle by allocating obj_exts arrays from each other [1]: What happened: a
KMALLOC_NORMAL slab's obj_exts array (used by allocation profiling / memcg accounting) is itself
kmalloc()'d from a KMALLOC_NORMAL cache, so the "slab holds another slab's obj_exts array" relation can
form cycles. With sizeof(struct slabobj_ext) == 16 and the host's geometry: - kmalloc-512 has 64
objects/slab -> array is 64*16 == 1024 bytes, served from kmalloc-1k; - kmalloc-1k has 32 objects/slab ->
array is 32*16 == 512 bytes, served from kmalloc-512. A kmalloc-512 slab and a kmalloc-1k slab therefore
hold each other's obj_exts array. Discarding one frees the other's array, which empties and discards that
slab, which frees the first's array, and so on: __free_slab() -> free_slab_obj_exts() -> kfree() ->
discard_slab() -> __free_slab() recurses along the cycle until the stack is exhausted. With memory
allocation profiling, this allows unbounded recursion in the free path and led to a stack overflow on a
production host in the Meta fleet [1]: BUG: TASK stack guard page was hit Oops: stack guard page RIP:
0010:kfree+0x8/0x5d0 Call Trace: __free_slab+0x66/0xc0 kfree+0x3f0/0x5d0 ... ( ~125x __free_slab <-> kfree
) ... <kernel driver freeing a resource> do_syscall_64 It is proposed [1] to resolve this issue by always
serving the obj_exts array allocation from kmalloc caches (or large kmalloc) of sizes larger than the
object size. However, as pointed out by Vlastimil Babka [2], this can waste an excessive amount of memory
as slabs from large kmalloc sizes (e.g. kmalloc-8k) generally need obj_exts arrays much smaller than the
object size. Therefore, rather than bumping the size, let us take a different approach; disallow formation
of cycles between kmalloc types when allocating obj_exts arrays. Currently, all obj_exts arrays are served
from normal kmalloc caches. Cycles cannot be created if obj_exts arrays of normal kmalloc caches are
served from a special kmalloc type that can never have obj_exts arrays. To achieve this, create a new
kmalloc type called KMALLOC_NO_OBJ_EXT. KMALLOC_NO_OBJ_EXT caches are created with SLAB_NO_OBJ_EXT flag
when either 1) memory allocation profiling is not permanently disabled, or 2) kmalloc types with a
priority higher than KMALLOC_CGROUP are aliased with KMALLOC_NORMAL. Sheaf bootstrapping for
KMALLOC_NO_OBJ_EXT caches now must be deferred because allocation of a barn can trigger obj_exts array
allocation of normal kmalloc caches when the KMALLOC_NO_OBJ_EXT cache for that size is not ready yet. For
simplicity, perform bootstrapping of sheaves for all kmalloc caches later. Introduce a new slab alloc
flag, SLAB_ALLOC_NO_OBJ_EXT, to prevent allocation of obj_exts arrays, and let kmalloc_slab() override the
type to KMALLOC_NO_OBJ_EXT when specified. Note that kmalloc_type() remains unchanged because
kmalloc_flags() bypasses the kmalloc fastpath. Do not pass SLAB_ALLOC_NO_RECURSE to kmalloc_flags() in
alloc_slab_obj_exts() and instead use SLAB_ALLOC_NO_OBJ_EXT only when the objects are allocated from
normal kmalloc caches. While this prevents unbounded recursive allocation of obj_exts, it allows
KMALLOC_NO_OBJ_EXT caches to have sheaves. Since sheaf allocations specify SLAB_ALLOC_NO_RECURSE that
prevents allocation of both sheaves and obj_exts arrays, the recursion depth is bounded. obj_exts arrays
for non- ---truncated--- (CVE-2026-74576)

Solution

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

Plugin Details

Severity: High

ID: 471375

Version: Revision 1.6

Type: Local

Family: Google COS Security Checks

Published: 10/3/2026

Updated: 10/7/2026

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

Risk Information

VPR

Risk Factor: Low

Score: 3

Percentile: 23.67

Vendor

Vendor Severity: LOW

CVSS v2

Risk Factor: High

Base Score: 7.8

Temporal Score: 5.8

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

CVSS Score Source: CVE-2026-74576

CVSS v3

Risk Factor: High

Base Score: 7.5

Temporal Score: 6.5

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

Reference Information

CVE: CVE-2026-74576

Detections

Analytics