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

high Tenable Cloud Security Plugin ID 475314

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: dma-buf: dma-heap: don't publish fd
before copy_to_user() succeeds DMA_HEAP_IOCTL_ALLOC allocates a dma-buf and installs an fd into the
caller's fd table via dma_buf_fd() -> fd_install() before dma_heap_ioctl() copies the result back to
userspace. If the trailing copy_to_user() fails, userspace never learns the fd number, but the fd (and the
underlying dma-buf reference) are already visible to other threads in the same process and are leaked for
the lifetime of the process. The obvious "close it on the failure path" fix is unsafe: once fd_install()
has run, another thread can already dup() the fd, send it via SCM_RIGHTS, or close() it and let its number
be reused, so a subsequent close_fd() from the ioctl path can operate on an unrelated file. This was
pointed out by Christian König on v1 [1]. Restructure the allocation path so that fd_install() is the
last, unfailable step of a successful ioctl: 1. heap->ops->allocate() creates the dma_buf. 2.
get_unused_fd_flags() reserves an fd number in the caller's fd table without publishing it, so no other
thread can observe it. 3. copy_to_user() delivers the fd number to userspace; on failure the fd is
returned with put_unused_fd() and the dma_buf reference is dropped with dma_buf_put(), leaving no user-
visible state behind. 4. dma_buf_fd_install() publishes the fd and emits the trace_dma_buf_fd tracepoint
-- from here on the ioctl cannot fail. A new dma_buf_fd_install() helper is introduced in dma-buf.c to
wrap fd_install() together with the DMA_BUF_TRACE() call, preserving the export tracing that dma_buf_fd()
provides. dma_heap_ioctl_allocate() is refactored to return the struct dma_buf * directly (returning
ERR_PTR on failure) so the caller holds the dmabuf reference across steps 3 and 4. The failure at step 3
is easily reachable from userspace: pass a struct dma_heap_allocation_data that lives in a page whose
protection is flipped to PROT_READ between copy_from_user() and copy_to_user() (e.g. via mprotect()).
Before this change each such ioctl leaks one dmabuf fd; after it, the fd table is unchanged on failure and
only /dev/dma_heap/<name> remains open. No UAPI or heap-driver interface change. [1]
https://lore.kernel.org/dri-devel/[email protected]/ (CVE-2026-89996)

Solution

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

Plugin Details

Severity: High

ID: 475314

Version: Revision 1.1

Type: Local

Family: Google COS Security Checks

Published: 10/16/2026

Updated: 10/16/2026

Risk Information

VPR

Risk Factor: Medium

Score: 6.3

Percentile: 96.36

Vendor

Vendor Severity: LOW

CVSS v2

Risk Factor: Medium

Base Score: 6.8

Temporal Score: 5

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

CVSS Score Source: CVE-2026-89996

CVSS v3

Risk Factor: High

Base Score: 7.1

Temporal Score: 6.2

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

Reference Information

CVE: CVE-2026-89996

Detections

Analytics