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 將 ioctx 排入佇列時會從 fd 取得新的結構檔案。從使用者空間完成 FUSE_WRITE 命令造成 fuse 伺服器呼叫 AIO 完成函式。完成放置 struct 檔案將延遲的 fput 排入 fuse 伺服器工作佇列。當 fuse 伺服器工作返回使用者空間時它必須執行延遲的 fput而如果是 fuseblk 伺服器它會以同步方式執行。
    從 fuse 伺服器執行緒同步傳送 FUSE_RELEASE 命令並非一個好主意因為用戶端程式可起始足夠多的同步 AIO使得所有 fuse 伺服器執行緒最後都進入 delayed_fput因此現在已沒有任何執行緒可處理已排入佇列的 fuse 命令。透過在關閉檔案時僅使用非同步 fput 來修正此問題並留下註解說明原因。 (CVE-2025-40220)

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

偵測

Linux Distros 未修補的弱點：CVE-2025-40220

medium Nessus Plugin ID 277496

版本 1.15