CVE-2025-40220
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-12-04

Last updated on: 2025-12-04

Assigner: kernel.org

Description
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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-12-04
Last Modified
2025-12-04
Generated
2026-05-07
AI Q&A
2025-12-04
EPSS Evaluated
2026-05-05
NVD
CVE-2025-40220
EUVD
EUVD-2025-201183
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability is a livelock issue in the Linux kernel's FUSE (Filesystem in Userspace) implementation, specifically affecting fuseblk workers. When a client program performs many asynchronous I/O (AIO) writes to a file and closes the file descriptor before the writes complete, the fuseblk server threads can end up waiting on themselves due to synchronous file put operations. This happens because the fuse server sends FUSE_RELEASE commands synchronously from its threads, causing all server threads to become stuck in delayed file put operations, leading to a hang or livelock situation.


How can this vulnerability impact me? :

This vulnerability can cause the system to hang or become unresponsive when using FUSE with fuseblk servers under heavy asynchronous I/O workloads. Specifically, if many simultaneous AIO writes are initiated and the file descriptor is closed prematurely, the fuse server threads can all become stuck waiting on each other, resulting in a livelock that prevents further processing of file operations. This can degrade system performance and availability.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by observing hangs or livelocks in fuseblk server threads, especially when running tests that perform asynchronous I/O (AIO) writes and close file descriptors before writes complete. You can check the stack traces of affected tasks to identify if they are stuck waiting for responses from the fuseblk server or itself. For example, use commands like: cat /proc/<pid>/task/<tid>/stack where <pid> and <tid> are process and thread IDs of fuseblk server tasks. Look for stack traces showing functions such as request_wait_answer, __fuse_simple_request, fuse_file_put, and fuse_release indicating the livelock condition.


What immediate steps should I take to mitigate this vulnerability?

To mitigate this vulnerability, ensure that the fuse server uses asynchronous file put (fput) operations when closing files instead of synchronous ones. This prevents fuse server threads from getting stuck in delayed_fput and avoids livelock. Applying the patch or update that fixes the fuse livelock by changing synchronous fputs to asynchronous fputs is the recommended immediate step.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart