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

medium Tenable Cloud Security Plugin ID 475140

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: nfsd: reject out-of-range nseconds in
NFSv3 SETATTR and create ops A client can send an NFSv3 SETATTR, CREATE, MKDIR, SYMLINK or MKNOD carrying
an atime or mtime whose nseconds field is out of range. The value is well-formed on the wire and decodes
cleanly into a valid uint32, but it is not a valid timespec64: tv_nsec must be less than NSEC_PER_SEC.
Nothing in the setattr path clamps it. notify_change() runs the time through timestamp_truncate(), which
does not reduce tv_nsec below NSEC_PER_SEC when the filesystem supports nanosecond granularity
(s_time_gran == 1), and the inode atime/mtime setters store it verbatim (only ctime is normalized, via
inode_set_ctime_to_ts()). The un-normalized value then corrupts on-disk metadata: ext4's
ext4_encode_extra_time() shifts tv_nsec left by EXT4_EPOCH_BITS, which overflows the 32-bit extra field
and clobbers the seconds-epoch bits, so the stored seconds (and thus the year) are wrong on read-back. XFS
with bigtime mis-stores the timestamp for the same reason. Validate the client-supplied atime/mtime in the
proc handlers and return NFS3ERR_INVAL before anything is changed. RFC 1813 lists NFS3ERR_INVAL for
SETATTR and describes it as the error for a value the server 'can not store ... in its own
representation'; the client maps it to EINVAL. Checking in the proc handlers, rather than in
nfsd_setattr(), keeps the rejection in front of object creation. The create operations create the object
before nfsd_create_setattr() runs, so a late failure would leave the new object behind and turn a non-
idempotent request into a namespace change that reports failure. The check is therefore done up front, for
the create operations before the object is created. tv_nsec is a long, so the comparison casts it to
unsigned long (the same width) rather than to u32, matching timespec64_valid(). A u32 cast would truncate
on 64-bit; the unsigned long cast also rejects a value that became negative when an out-of-range u32 wire
nseconds was assigned to a 32-bit long. Only client-supplied times are checked: SET_TO_SERVER_TIME
requests carry no client value. The sattrguard3 ctime is deliberately left alone: an out-of-range guard
simply never matches the object's ctime and yields NFS3ERR_NOT_SYNC via the existing guardtime comparison,
which is the protocol-correct outcome rather than rejecting the request. (CVE-2026-89666)

Solution

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

Plugin Details

Severity: Medium

ID: 475140

Version: Revision 1.1

Type: Local

Family: Google COS Security Checks

Published: 10/16/2026

Updated: 10/16/2026

Risk Information

VPR

Risk Factor: Low

Score: 3

Percentile: 23.74

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

CVSS v3

Risk Factor: Medium

Base Score: 5.5

Temporal Score: 4.8

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

Reference Information

CVE: CVE-2026-89666

Detections

Analytics