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 468384

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: drain in-flight DIO before
buffered write fallback generic/746 started failing intermittently on ext3 (no-extent inodes). The test
triggers 'Page cache invalidation failure on direct I/O' warnings and subsequent fsync returns -EIO.
Adding a 50ms delay between ext4_buffered_write_iter() and filemap_write_and_wait_range() in
ext4_dio_write_iter() makes the race almost always reproducible. On no-extent inodes, DIO writes to holes
cannot use unwritten extents, so ext4_iomap_alloc() leaves m_flags=0 and ext4_map_blocks() returns 0. The
iomap layer then returns -ENOTBLK, causing fallback to buffered I/O. The fallback path in
ext4_dio_write_iter() calls ext4_buffered_write_iter() which dirties pages, then does flush and
invalidate. However, there's an unprotected window between ext4_buffered_write_iter() returning (with
inode lock released) and the subsequent flush+invalidate. Concurrent async DIO completions from other
threads can run kiocb_invalidate_post_direct_write() during this window. If pages have been re-dirtied,
post-invalidation finds dirty pages and triggers the warning, setting -EIO in the error sequence. Consider
a file with two 4k extents: [hole][written]. Thread A does DIO to the written extent, while thread B does
DIO spanning both: kworker A (4k DIO, allocated block) kworker B (8k DIO, fallback)
----------------------------------- ---------------------------- inode_lock_shared() inode_lock_shared()
iomap_dio_rw(): iomap_dio_rw(): kiocb_invalidate_pages -> clean iomap_begin -> -ENOTBLK submit_bio (async)
dio->size = 0 inode_unlock_shared() inode_unlock_shared() [bio pending in block layer] /* fallback: lock
released */ ext4_buffered_write_iter() inode_lock(exclusive) generic_perform_write() -> dirty pages [0,
8k] inode_unlock(exclusive) /* pages dirty, no lock */ [bio completes] filemap_write_and_wait_range()
iomap_dio_complete() -> flush dirty pages kiocb_invalidate_post_direct_write() invalidate_mapping_pages()
invalidate_inode_pages2_range() -> finds dirty page! -> dio_warn_stale_pagecache() -> errseq_set(-EIO)
This issue can be triggered through normal I/O paths, not just intentionally overlapping DIO writes from
userspace. For example, generic/746 uses a loop device where multiple kworkers issue concurrent I/O to the
backing file. Additionally, when block_size < folio_size, non-overlapping DIO writes that share a large
folio can also trigger the race. Add inode_dio_wait() in ext4_buffered_write_iter() before
ext4_write_checks() to drain all in-flight DIO. This ensures that all DIO clears existing pages before
submitting IO (via kiocb_invalidate_pages()), all BIO waits for all DIO to complete (via
inode_dio_wait()), and ext4_write_checks() observes the inode size after all completed DIO so that
ext4_block_zero_eof() does not race with in-flight DIO, thus eliminating the race. (CVE-2026-92501)

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: 468384

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: Low

Score: 3

Percentile: 23.58

Vendor

Vendor Severity: LOW

CVSS v2

Risk Factor: Medium

Base Score: 4.7

Temporal Score: 3.5

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

CVSS Score Source: CVE-2026-92501

CVSS v3

Risk Factor: Medium

Base Score: 4.7

Temporal Score: 4.1

Vector: CVSS:3.0/AV:L/AC:H/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/17/2026

Reference Information

CVE: CVE-2026-92501

Detections

Analytics