Google: sys-kernel/csql-kernel-6_6, sys-kernel/lakitu-kernel-6_6, sys-kernel/lakitu-nc-kernel-6_6, sys-kernel/lakitu-vgpu-kernel-6_6: security update to 18867.584.3

high Tenable Cloud Security Plugin ID 467153

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/vmalloc: acquire init_mm lock on
huge vmap to avoid ptdump UAF Patch series "mm: fix UAF caused by race between ptdump and vmap pgtable
freeing", v6. Kernel page table walkers fall into two broad categories - those ranges where no exclusion
is required via walk_kernel_page_table_range_lockless() and those where exclusion is required via
walk_kernel_page_table_range() or walk_page_range_debug(). The former category is used only by arm64 arch
code operating on ranges it both wholly owns and does not concurrently write. The latter category consists
of kernel page table walkers operating on ranges that are wholly owned (but which need exclusion against
concurrent writers). The lock used for exclusion is the mmap lock, and for kernel ranges this is the mmap
lock on init_mm. ptdump is a special case being both the only user of walk_page_range_debug(), and the
only case in which it walks ranges it does not own. This presents a problem, as page tables may be freed
under ptdump. And indeed there is a use-after-free bug in the kernel as a result, which this series
addresses. vmap promotes page tables to huge leaf entries where possible, freeing the lower page table
when it does. It does this with no meaningful locks held against concurrent ptdump walks. As a result,
use-after-free can currently occur. This series addresses the issue by having the vmap huge promotion
logic acquire the mmap read lock while both setting the huge page table entry and freeing the prior leaf
page table. The ptdump code already acquires the mmap write lock, so by doing so we ensure that the ptdump
walker only ever observes either the huge page table entry or the existing page table entry, and nothing
is freed underneath it. A mitigation for this issue was already applied for arm64 in commit fa93b45fd397
("arm64: Enable vmalloc-huge with ptdump"), which this series has to deal with carefully. This mitigation
resolves the issue by acquiring the mmap read lock on init_mm on vmap page table free if a ptdump is in
progress. However the fix in this series would cause a deadlock if we were to simply apply it for arm64
without also reverting the change. This is because vmap may acquire the read lock before ptdump attempts
to acquire the write lock, which then gets queued, and rwsem starvation rules mean that the
(unacknowledged) nested mmap read lock in the arm64 code would also block, meaning the original read lock
is never released and thus deadlock. This series works around this by #ifndef CONFIG_ARM64'ing the mmap
read lock in vmap logic, then partially reverting commit fa93b45fd397 ("arm64: Enable vmalloc-huge with
ptdump"), keeping the enablement of huge vmap support, and removing the ifdeffery with the partial revert
patch. There are related issues that are also addressed in this series: * x86 page attribute logic,
specifically Change Page Attributes (CPA), implements a feature whereby huge ranges can be collapsed into
huge leaf entries. This can similarly cause a UAF when done in parallel with a ptdump walk, so similarly
acquire the init_mm mmap lock to avoid this. * The CPA logic allows concurrent page table manipulation and
CPA collapse, meaning the former risks accessing a page table the latter frees. Fix this by acquiring mmap
write lock on init_mm across the whole CPA collapse operation and read lock on the page table
manipulation. * x86 and arm64 permit walks of non-kernel mm's (both allowing efi mm walks, and in x86's
case arbitrary mm's), so we ensure kernel mappings remain stable by locking the init_mm as well as the mm
being walked. The ordering of patches is established for both strict dependencies (the arm64 partial
revert in particular has to be done after the vmap changes) and logical ones (the non-kernel mm fix only
makes sense once the vmap/CPA fixes are in place). This patch (of 3): Currently there is a nasty ra
---truncated--- (CVE-2026-74672)

Solution

Update the sys-kernel/csql-kernel-6_6 library and its related packages to version 18867.584.3 or later.

Plugin Details

Severity: High

ID: 467153

Version: Revision 1.1

Type: Local

Family: Google COS Security Checks

Published: 10/2/2026

Updated: 10/2/2026

Risk Information

VPR

Risk Factor: Medium

Score: 4.9

Percentile: 58.15

Vendor

Vendor Severity: LOW

CVSS v2

Risk Factor: High

Base Score: 7.2

Temporal Score: 5.3

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

CVSS Score Source: CVE-2026-74672

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

Reference Information

CVE: CVE-2026-74672

Detections

Analytics