Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - fuse修复从 fuseblk 工作线程放置的同步文件中的活锁。我发现对 fuseblk 服务器运行 generic/323 时存在挂起。此测试打开一个文件，对该文件描述符发起大量 AIO 写入，并在写入完成之前关闭该文件描述符。不足为奇AIO 训练线程大多等待 fuseblk 服务器的响应 # 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 但 /weird/ 部分是 fuseblk 服务器线程正在等待来自其自身的响应# 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 fuseblk 服务器是fuse2fs因此服务器本身没有什么令人高兴的地方。为什么 fuse 服务器要调用 fuse_file_put？fstest 的提交消息在一定程度上说明了这一点通过在调用 io_destroy 之前关闭文件描述符几乎可以保证 ioctx 上的最后放置将在中断上下文中在 I/O 完成期间完成。
    原来如此。AIO fget 在排入 ioctx 队列时从 fd 获取新的 struct file。从用户空间完成 FUSE_WRITE 命令会造成 fuse 服务器调用 AIO 完成函数。完成会将延迟的 fput 放入 struct file 队列中以供 fuse 服务器任务使用。当 fuse 服务器任务返回到用户空间时它必须运行延迟的 fput对于 fuseblk 服务器它会同步运行。
    从 fuse 服务器线程同步发送 FUSE_RELEASE 命令不是一个好方法因为客户端程序可以发起足够多的同步 AIO使得所有 fuse 服务器线程都在 delayed_fput 中结束现在没有任何线程可用于处理排队的 fuse 命令。通过在关闭文件时仅使用异步 fputs 修复此问题并留下注释解释原因。 (CVE-2025-40220)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

检测

Linux Distros 未修补的漏洞：CVE-2025-40220

medium Nessus 插件 ID 277496

版本 1.23