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 19165.0.0

high Tenable Cloud Security Plugin ID 467938

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: nexthop: Increase weight to u16
In CLOS networks, as link failures occur at various points in the network, ECMP weights of the involved
nodes are adjusted to compensate. With high fan-out of the involved nodes, and overall high number of
nodes, a (non-)ECMP weight ratio that we would like to configure does not fit into 8 bits. Instead of,
say, 255:254, we might like to configure something like 1000:999. For these deployments, the 8-bit weight
may not be enough. To that end, in this patch increase the next hop weight from u8 to u16. Increasing the
width of an integral type can be tricky, because while the code still compiles, the types may not check
out anymore, and numerical errors come up. To prevent this, the conversion was done in two steps. First
the type was changed from u8 to a single-member structure, which invalidated all uses of the field. This
allowed going through them one by one and audit for type correctness. Then the structure was replaced with
a vanilla u16 again. This should ensure that no place was missed. The UAPI for configuring nexthop group
members is that an attribute NHA_GROUP carries an array of struct nexthop_grp entries: struct nexthop_grp
{ __u32 id; /* nexthop id - must exist */ __u8 weight; /* weight of this nexthop */ __u8 resvd1; __u16
resvd2; }; The field resvd1 is currently validated and required to be zero. We can lift this requirement
and carry high-order bits of the weight in the reserved field: struct nexthop_grp { __u32 id; /* nexthop
id - must exist */ __u8 weight; /* weight of this nexthop */ __u8 weight_high; __u16 resvd2; }; Keeping
the fields split this way was chosen in case an existing userspace makes assumptions about the width of
the weight field, and to sidestep any endianness issues. The weight field is currently encoded as the
weight value minus one, because weight of 0 is invalid. This same trick is impossible for the new
weight_high field, because zero must mean actual zero. With this in place: - Old userspace is guaranteed
to carry weight_high of 0, therefore configuring 8-bit weights as appropriate. When dumping nexthops with
16-bit weight, it would only show the lower 8 bits. But configuring such nexthops implies existence of
userspace aware of the extension in the first place. - New userspace talking to an old kernel will work as
long as it only attempts to configure 8-bit weights, where the high-order bits are zero. Old kernel will
bounce attempts at configuring >8-bit weights. Renaming reserved fields as they are allocated for some
purpose is commonly done in Linux. Whoever touches a reserved field is doing so at their own risk.
nexthop_grp::resvd1 in particular is currently used by at least strace, however they carry an own copy of
UAPI headers, and the conversion should be trivial. A helper is provided for decoding the weight out of
the two fields. Forcing a conversion seems preferable to bending backwards and introducing anonymous
unions or whatever. (CVE-2024-14040)

Solution

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

Plugin Details

Severity: High

ID: 467938

Version: Revision 1.6

Type: Local

Family: Google COS Security Checks

Published: 10/3/2026

Updated: 10/6/2026

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

Risk Information

VPR

Risk Factor: Medium

Score: 4.9

Percentile: 58.14

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-2024-14040

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: 7/26/2026

Reference Information

CVE: CVE-2024-14040

Detections

Analytics