Google: sys-kernel/cchost-kernel-6_12, sys-kernel/csql-kernel-6_12: security update to 19506.0.32

medium Tenable Self-Hosted Container Security Plugin ID 472512

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: btrfs: fix racy bitfield write in
btrfs_clear_space_info_full() From the memory-barriers.txt document regarding memory barrier ordering
guarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to
modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize
parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given
bitfield must be protected by one lock. If two fields in a given bitfield are protected by different
locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt
the value of an adjacent field. btrfs_space_info has a bitfield sharing an underlying word consisting of
the fields full, chunk_alloc, and flush: struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8
*/ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4
*/ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ... Therefore, to be
safe from parallel read-modify-writes losing a write to one of the bitfield members protected by a lock,
all writes to all the bitfields must use the lock. They almost universally do, except for
btrfs_clear_space_info_full() which iterates over the space_infos and writes out found->full = 0 without a
lock. Imagine that we have one thread completing a transaction in which we finished deleting a block_group
and are thus calling btrfs_clear_space_info_full() while simultaneously the data reclaim ticket
infrastructure is running do_async_reclaim_data_space(): T1 T2 btrfs_commit_transaction
btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1
do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets))
space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0
spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1 and now
data_sinfo->flush is 1 but the reclaim worker has exited. This breaks the invariant that flush is 0 iff
there is no work queued or running. Once this invariant is violated, future allocations that go into
__reserve_bytes() will add tickets to space_info->tickets but will see space_info->flush is set to 1 and
not queue the work. After this, they will block forever on the resulting ticket, as it is now impossible
to kick the worker again. I also confirmed by looking at the assembly of the affected kernel that it is
doing RMW operations. For example, to set the flush (3rd) bit to 0, the assembly is: andb $0xfb,0x60(%rbx)
and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax) So I think this is really a bug
on practical systems. I have observed a number of systems in this exact state, but am currently unable to
reproduce it. Rather than leaving this footgun lying around for the future, take advantage of the fact
that there is room in the struct anyway, and that it is already quite large and simply change the three
bitfield members to bools. This avoids writes to space_info->full having any effect on ---truncated---
(CVE-2025-68358)

Solution

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

Plugin Details

Severity: Medium

ID: 472512

Version: Revision 1.1

Type: Local

Family: Google COS Security Checks

Published: 10/3/2026

Updated: 10/3/2026

Risk Information

VPR

Risk Factor: Low

Score: 3

Percentile: 23.66

Vendor

Vendor Severity: LOW

CVSS v2

Risk Factor: Medium

Base Score: 4.6

Temporal Score: 3.4

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

CVSS Score Source: CVE-2025-68358

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: 12/24/2025

Reference Information

CVE: CVE-2025-68358

Detections

Analytics