CVE-2025-40220

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