In the Linux kernel, the following vulnerability has been resolved: **Fuse: Fixed a livelock issue in synchronous file put operations performed by fuseblk workers.** I observed a hang when running the `generic/323` test against a fuseblk server. This test creates a file, initiates multiple AIO writes to that file descriptor, and closes the file descriptor before the writes are completed. unsurprisingly, the AIO-related threads were 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 were also 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 actually **fuse2fs**, so there’s nothing particularly exciting about the server itself. So why does the fuse server call **fuse_file_put**? The commit message for the `fstest` test provides some insight into this: “By closing the file descriptor before calling `ioDestroy`, you essentially ensure that the last `put` operation on the `ioctx` will be performed in an interrupt context (during I/O completion).” Ah… When an AIO thread retrieves a new `struct file` from the file descriptor, the completion of the `FUSE_WRITE` command causes the fuse server to call the AIO completion function. This operation queues a delayed `fput` operation for the fuse server task. When the fuse server task returns to user space, it must execute the delayed `fput` operation. In the case of a fuseblk server, this is done synchronously. **Sending the `FUSE_RELEASE` command synchronously from fuse server threads is a bad idea**, because a client program can initiate too many simultaneous AIO operations, causing all fuse server threads to end up in a state where they cannot handle the queued commands. **This issue is fixed by using only asynchronous `fputs` when closing files**, with a comment explaining why this change was made.

Query Builder