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

medium Tenable Self-Hosted Container Security Plugin ID 475251

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: fs: don't return -EINVAL for
successful nested thaw Commit 7366f8b6fc6a ("fs: handle freezing from multiple devices") replaced the
freeze_holders bitmask with per-holder counters to allow nested freezes. In the bitmask version, a thaw
that released a shared hold while another holder remained returned 0. Since the rework,
thaw_super_locked() drops the freeze reference via freeze_dec() but then returns -EINVAL when other
freezers remain, misinforming the caller: the thaw did succeed, the superblock just stays frozen for the
remaining holders. This breaks bdev-initiated freezing. When a filesystem is frozen with FIFREEZE and
additionally frozen via bdev_freeze() -- which nests by design, see fs_bdev_freeze() -- the subsequent
bdev_thaw() receives -EINVAL from the holder op although its freeze reference was dropped, and therefore
keeps bd_fsfreeze_count elevated. Then device-mapper's unlock_fs() ignores bdev_thaw()'s return value, so
nothing rebalances the count. After the user's FITHAW and umount, the block device can never be mounted
again: dm-1: Can't mount, blockdev is frozen There is no way for userspace to drop the leaked count; only
destroying the block device (or a reboot) recovers the device. Reproducer (any kernel since v6.8): dmsetup
create dut --table "0 $(blockdev --getsz "$DEV") linear $DEV 0" mkfs.ext4 /dev/mapper/dut mount
/dev/mapper/dut /mnt fsfreeze --freeze /mnt # freeze_ucount == 1 dmsetup suspend dut # bd_fsfreeze_count
== 1, ucount == 2 dmsetup resume dut # ucount 2 -> 1, but thaw_super() # returns -EINVAL, so bdev_thaw() #
keeps bd_fsfreeze_count at 1 fsfreeze --unfreeze /mnt # filesystem thaws fine umount /mnt mount
/dev/mapper/dut /mnt # EBUSY, forever The same happens with fsfreeze held across an LVM snapshot of the
origin volume. fs_bdev_thaw()'s documentation already describes the intended semantics: "If this function
returns zero it doesn't mean that the filesystem is unfrozen as it may have been frozen multiple times".
Restore them by returning 0 when a nested thaw drops its hold while other freezers remain. Thawing without
holding a freeze still fails with -EINVAL as may_unfreeze() rejects that case before the reference count
is touched. (CVE-2026-97902)

Solution

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

Plugin Details

Severity: Medium

ID: 475251

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.6

Vendor

Vendor Severity: LOW

CVSS v2

Risk Factor: Medium

Base Score: 4.9

Temporal Score: 3.6

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

CVSS Score Source: CVE-2026-97902

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

Reference Information

CVE: CVE-2026-97902

Detections

Analytics