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

high Tenable Cloud Security Plugin ID 469406

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: ext4: clear stale xarray tags on
folios skipped during writeback In data=journal mode, the writeback thread can hit the
WARN_ON_ONCE(sb_rdonly(sb)) in ext4_journal_check_start() while the superblock is being remounted read-
only during reboot: Workqueue: writeback wb_workfn (flush-253:0) RIP:
0010:ext4_journal_check_start+0x8b/0xd0 Call Trace: __ext4_journal_start_sb+0x3c/0x1e0
mpage_prepare_extent_to_map+0x4af/0x580 ext4_do_writepages+0x3c0/0x1080 ext4_writepages+0xc8/0x1a0
do_writepages+0xc4/0x180 __writeback_single_inode+0x45/0x2f0 writeback_sb_inodes+0x26b/0x5d0
__writeback_inodes_wb+0x54/0x100 wb_writeback+0x1ac/0x320 wb_workfn+0x394/0x470 And followed by the
warning: EXT4-fs warning (device vda1): ext4_evict_inode:195: inode #6263: comm (sd-umount): data will be
lost This issue is not reproduced every time, but frequently. The reproduction step is to create a VM with
8 CPUs, 16G memory and setup data=journal: sudo tune2fs -o journal_data /dev/vda1 Run fio: rm -f fiotest
fio --name=fiotest --rw=randwrite --bs=4k --runtime=6 --ioengine=libaio --iodepth=256 --numjobs=8
--filename=fiotest --filesize=30G --group_reporting Reboot the VM, and check the console output from:
virsh console testvm But there is no dirty inode, folio_clear_dirty_for_io clears PG_dirty but leaves tags
PAGECACHE_TAG_DIRTY and PAGECACHE_TAG_TOWRITE set which are only cleared by __folio_start_writeback. In
data=journal mode, jbd2 checkpoints the journalled data to its final location and clears its own dirty
flag without touching folio PG_dirty or xarray dirty flags. The commit f4a2b42e7891 ("ext4: fix stale
xarray tags after writeback") fixes when PG_dirty is still set but there is no dirty page. Another case is
PG_dirty is cleared, but PAGECACHE_TAG_DIRTY and PAGECACHE_TAG_TOWRITE is still set. In this case,
writeback thread checks clean folio and skips it in mpage_prepare_extent_to_map: if
(!folio_test_dirty(folio) || ... folio_unlcok(folio); continue And never reaches ext4_bio_write_folio
where the commit f4a2b42e7891 clears the stale xarray tags. Print debug logs after the filesystem is
remounted read-only: writepages RDONLY nrpages=2048 dirtytag=1 wbtag=0 towrite=1 sync=0 And all folios are
actually clean: folio idx=3 dirty=0 wb=0 checked=0 dirtybuf=0 jbddirty=0 mapped=1 ... We need to clear the
xarray stale tags for such clean folios by cycling them through writeback in the skip path, the same way
f4a2b42e7891 does in ext4_bio_write_folio. (CVE-2026-92502)

Solution

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

Plugin Details

Severity: High

ID: 469406

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

Vendor

Vendor Severity: LOW

CVSS v2

Risk Factor: Medium

Base Score: 5.4

Temporal Score: 4

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

CVSS Score Source: CVE-2026-92502

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: 9/17/2026

Reference Information

CVE: CVE-2026-92502

Detections

Analytics