Google: sys-kernel/csql-kernel-6_1, sys-kernel/csql-kernel-6_6: security update to 18613.439.65

medium Tenable Cloud Security Plugin ID 472131

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: fuse: fix livelock in synchronous file
put from fuseblk workers I observed a hang when running generic/323 against a fuseblk server. This test
opens a file, initiates a lot of AIO writes to that file descriptor, and closes the file descriptor before
the writes complete. Unsurprisingly, the AIO exerciser threads are mostly stuck waiting for responses from
the fuseblk server: # cat /proc/372265/task/372313/stack [<0>] request_wait_answer+0x1fe/0x2a0 [fuse]
[<0>] __fuse_simple_request+0xd3/0x2b0 [fuse] [<0>] fuse_do_getattr+0xfc/0x1f0 [fuse] [<0>]
fuse_file_read_iter+0xbe/0x1c0 [fuse] [<0>] aio_read+0x130/0x1e0 [<0>] io_submit_one+0x542/0x860 [<0>]
__x64_sys_io_submit+0x98/0x1a0 [<0>] do_syscall_64+0x37/0xf0 [<0>]
entry_SYSCALL_64_after_hwframe+0x4b/0x53 But the /weird/ part is that the fuseblk server threads are
waiting for responses from itself: # cat /proc/372210/task/372232/stack [<0>]
request_wait_answer+0x1fe/0x2a0 [fuse] [<0>] __fuse_simple_request+0xd3/0x2b0 [fuse] [<0>]
fuse_file_put+0x9a/0xd0 [fuse] [<0>] fuse_release+0x36/0x50 [fuse] [<0>] __fput+0xec/0x2b0 [<0>]
task_work_run+0x55/0x90 [<0>] syscall_exit_to_user_mode+0xe9/0x100 [<0>] do_syscall_64+0x43/0xf0 [<0>]
entry_SYSCALL_64_after_hwframe+0x4b/0x53 The fuseblk server is fuse2fs so there's nothing all that
exciting in the server itself. So why is the fuse server calling fuse_file_put? The commit message for the
fstest sheds some light on that: "By closing the file descriptor before calling io_destroy, you pretty
much guarantee that the last put on the ioctx will be done in interrupt context (during I/O completion).
Aha. AIO fgets a new struct file from the fd when it queues the ioctx. The completion of the FUSE_WRITE
command from userspace causes the fuse server to call the AIO completion function. The completion puts the
struct file, queuing a delayed fput to the fuse server task. When the fuse server task returns to
userspace, it has to run the delayed fput, which in the case of a fuseblk server, it does synchronously.
Sending the FUSE_RELEASE command sychronously from fuse server threads is a bad idea because a client
program can initiate enough simultaneous AIOs such that all the fuse server threads end up in
delayed_fput, and now there aren't any threads left to handle the queued fuse commands. Fix this by only
using asynchronous fputs when closing files, and leave a comment explaining why. (CVE-2025-40220)

Solution

Update the sys-kernel/csql-kernel-6_1 library and its related packages to version 18613.439.65 or later.

Plugin Details

Severity: Medium

ID: 472131

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

Vendor

Vendor Severity: MEDIUM

CVSS v2

Risk Factor: Medium

Base Score: 5.2

Temporal Score: 3.8

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

CVSS Score Source: CVE-2025-40220

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: 11/14/2025

Reference Information

CVE: CVE-2025-40220

Detections

Analytics