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

high Tenable Cloud Security Plugin ID 470521

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: apparmor: fix cred UAF caused by
begin_current_label_crit_section() AppArmor's begin_current_label_crit_section() is a scary function
called from lots of LSM hooks (in particular VFS/socket-related ones) that checks if the label referenced
by the current creds is marked FLAG_STALE, and if so, attempts to use aa_replace_current_label() to
replace the creds with an updated version that uses a new label. The first problem with this is that it
would directly lead to UAF of `struct cred` if anything in the kernel takes a pointer to the current creds
and accesses these past a security hook invocation that replaces creds, like so: ``` const struct cred
*cred = current_cred(); alloc_file_pseudo(...); uid_t uid = cred->euid; ``` I don't know if anything in
the kernel actually does this, but I think it is very surprising that this pattern could lead to UAF. The
second problem is that things go wrong when aa_replace_current_label() runs with overridden credentials.
aa_replace_current_label() bails out if `current_cred() != current_real_cred()` (mirroring the check in
proc_pid_attr_write()), but this check can't actually reliably detect overridden credentials because the
overridden creds can be the same as the objective creds. So in approximately the following scenario,
things go wrong: 1. task begins with <creds A> (as both objective and subjective creds), with refcount=2
2. task grabs an extra reference on <creds A> for overriding 3. task calls override_creds(<creds A>),
which returns a pointer to the old subjective creds (<creds A>) 4. task enters AppArmor LSM hook 5.
AppArmor checks that objective/subjective creds are equal 6. AppArmor replaces both cred pointers with
<creds B> and drops 2 refs on <creds A> 7. task leaves AppArmor LSM hook 8. task calls revert_creds(<creds
A>) 9. now task->cred is <creds A> while task->real_cred is <creds B>, but the task_struct logically holds
two references to <creds B> 10. another task drops the extra reference on <creds A> that was used for
overriding, refcount drops to 0 11. now task->real_cred points to freed creds At this point, any access to
current_cred() will be UAF. I have a test case where I run aa-disable on a profile while a process using
that profile is blocked on splice() from a FUSE passthrough file into a full pipe; after the profile
update, the pipe becomes empty, splice() resumes, the credentials go out of sync, and a subsequent
getuid() syscall results in a KASAN UAF splat. To fix this, instead of directly replacing creds, do it via
task_work that will run at the end of the current syscall. (The point in time at which the cred
replacement happens should have no correctness impact; it is just a performance optimization to avoid
unnecessarily touching the refcount of the new label.) Note that AppArmor still performs direct cred
replacements in the sb_pivotroot LSM hook after this change, and that direct cred replacements can still
happen in VFS ->write() callbacks via proc_pid_attr_write(). There are two options for what to do with
aa_dup_task_ctx(): Either explicitly reset new->label_replacement_pending after the entire aa_task_ctx has
been copied, or switch to manually copying members over. I am switching to manually copying members over
because that should make bugs more obvious. (CVE-2026-89762)

Solution

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

Plugin Details

Severity: High

ID: 470521

Version: Revision 1.3

Type: Local

Family: Google COS Security Checks

Published: 10/3/2026

Updated: 10/3/2026

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

Risk Information

VPR

Risk Factor: Medium

Score: 6.9

Percentile: 96.59

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

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

Reference Information

CVE: CVE-2026-89762

Detections

Analytics