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

high Tenable Self-Hosted Container Security Plugin ID 466180

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: net/mlx5e: Fix HV VHCA stats zero-
sized buffer allocation mlx5e_hv_vhca_stats_create() is called from mlx5e_nic_enable(), before
mlx5e_open(). At that point priv->stats_nch is still zero, because it is only ever incremented in
mlx5e_channel_stats_alloc(), which is reached only from mlx5e_open_channel().
mlx5e_hv_vhca_stats_buf_size() therefore returns 0, and kvzalloc(0, GFP_KERNEL) returns ZERO_SIZE_PTR
((void *)16) rather than NULL. The "if (!buf)" guard does not catch this, and mlx5e_hv_vhca_stats_create()
completes "successfully" with priv->stats_agent.buf set to ZERO_SIZE_PTR. Once channels are opened
(priv->stats_nch > 0) and the hypervisor enables stats reporting, mlx5e_hv_vhca_stats_work() recomputes
buf_len using the new non-zero stats_nch and calls memset(buf, 0, buf_len) on ZERO_SIZE_PTR, faulting at
address 0x10. Allocate the buffer based on priv->max_nch, which is set in mlx5e_priv_init() and is the
upper bound on stats_nch: - Add a separate helper mlx5e_hv_vhca_stats_buf_max_size() that returns
sizeof(per_ring_stats) * max(max_nch, stats_nch), and use it for the kvzalloc() in
mlx5e_hv_vhca_stats_create(). - Keep mlx5e_hv_vhca_stats_buf_size() (which returns based on stats_nch) for
the worker's active payload size, so the wire format (block->rings = stats_nch) and the amount of data
filled by mlx5e_hv_vhca_fill_stats() are unchanged. The max(max_nch, stats_nch) guard handles the rare
case where mlx5e_attach_netdev() recomputes max_nch downward across a detach/resume cycle while
priv->stats_nch persists (mlx5e_detach_netdev does not call mlx5e_priv_cleanup, so stats_nch is only reset
when the netdev is destroyed). Without the guard, the worker could compute buf_len from stats_nch and
overrun the smaller buffer allocated based on the reduced max_nch. Allocating a non-zero buffer also makes
the kvzalloc() failure path in mlx5e_hv_vhca_stats_create() reachable for the first time: it returns early
without (re)creating the agent. Clear priv->stats_agent.{agent,buf} in mlx5e_hv_vhca_stats_destroy() after
freeing them, so that if a later create() bails out on this path, a subsequent teardown does not double-
free the stale agent/buffer left from a previous enable/disable cycle. This mirrors the existing mlx5e
pattern of preallocating arrays of size max_nch (e.g. priv->channel_stats) and lazily populating entries
up to stats_nch on demand. (CVE-2026-72343)

Solution

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

Plugin Details

Severity: High

ID: 466180

Version: Revision 1.3

Type: Local

Family: Google COS Security Checks

Published: 10/2/2026

Updated: 10/3/2026

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

Risk Information

VPR

Risk Factor: Medium

Score: 4.9

Percentile: 58.27

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

CVSS v3

Risk Factor: High

Base Score: 8.4

Temporal Score: 7.3

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

Reference Information

CVE: CVE-2026-72343

Detections

Analytics