{"cve":"CVE-2025-40220","nvd":{"published":"2025-12-04T15:15:58.033","modified":"2026-10-19T21:10:00.160","status":"Deferred","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nfuse: fix livelock in synchronous file put from fuseblk workers\n\nI observed a hang when running generic/323 against a fuseblk server.\nThis test opens a file, initiates a lot of AIO writes to that file\ndescriptor, and closes the file descriptor before the writes complete.\nUnsurprisingly, the AIO exerciser threads are mostly stuck waiting for\nresponses from the fuseblk server:\n\n# cat /proc/372265/task/372313/stack\n[<0>] request_wait_answer+0x1fe/0x2a0 [fuse]\n[<0>] __fuse_simple_request+0xd3/0x2b0 [fuse]\n[<0>] fuse_do_getattr+0xfc/0x1f0 [fuse]\n[<0>] fuse_file_read_iter+0xbe/0x1c0 [fuse]\n[<0>] aio_read+0x130/0x1e0\n[<0>] io_submit_one+0x542/0x860\n[<0>] __x64_sys_io_submit+0x98/0x1a0\n[<0>] do_syscall_64+0x37/0xf0\n[<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nBut the /weird/ part is that the fuseblk server threads are waiting for\nresponses from itself:\n\n# cat /proc/372210/task/372232/stack\n[<0>] request_wait_answer+0x1fe/0x2a0 [fuse]\n[<0>] __fuse_simple_request+0xd3/0x2b0 [fuse]\n[<0>] fuse_file_put+0x9a/0xd0 [fuse]\n[<0>] fuse_release+0x36/0x50 [fuse]\n[<0>] __fput+0xec/0x2b0\n[<0>] task_work_run+0x55/0x90\n[<0>] syscall_exit_to_user_mode+0xe9/0x100\n[<0>] do_syscall_64+0x43/0xf0\n[<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nThe fuseblk server is fuse2fs so there's nothing all that exciting in\nthe server itself.  So why is the fuse server calling fuse_file_put?\nThe commit message for the fstest sheds some light on that:\n\n\"By closing the file descriptor before calling io_destroy, you pretty\nmuch guarantee that the last put on the ioctx will be done in interrupt\ncontext (during I/O completion).\n\nAha.  AIO fgets a new struct file from the fd when it queues the ioctx.\nThe completion of the FUSE_WRITE command from userspace causes the fuse\nserver to call the AIO completion function.  The completion puts the\nstruct file, queuing a delayed fput to the fuse server task.  When the\nfuse server task returns to userspace, it has to run the delayed fput,\nwhich in the case of a fuseblk server, it does synchronously.\n\nSending the FUSE_RELEASE command sychronously from fuse server threads\nis a bad idea because a client program can initiate enough simultaneous\nAIOs such that all the fuse server threads end up in delayed_fput, and\nnow there aren't any threads left to handle the queued fuse commands.\n\nFix this by only using asynchronous fputs when closing files, and leave\na comment explaining why.","cvss_v4":null,"cvss_v3":null,"cwes":[],"references":["https://git.kernel.org/stable/c/26e5c67deb2e1f42a951f022fdf5b9f7eb747b01","https://git.kernel.org/stable/c/548e1f2bac1d4df91a6138f26bb4ab00323fd948","https://git.kernel.org/stable/c/83b375c6efef69b1066ad2d79601221e7892745a","https://git.kernel.org/stable/c/b26923512dbe57ae4917bafd31396d22a9d1691a","https://git.kernel.org/stable/c/bfd17b6138df0122a95989457d8e18ce0b86165e"],"products":[],"source":"nvd","synced_at":"2026-10-21T03:43:09.190223697+00:00"},"epss":{"cve":"CVE-2025-40220","score":0.00193,"percentile":0.08832,"date":"2026-10-25"},"kev":null,"osv":[],"attribution":["This product uses the NVD API but is not endorsed or certified by the NVD.","EPSS scores: FIRST Exploit Prediction Scoring System, https://www.first.org/epss","Known exploited vulnerabilities: CISA Known Exploited Vulnerabilities Catalog, https://www.cisa.gov/known-exploited-vulnerabilities-catalog","Package advisories: OSV (https://osv.dev), from the GitHub Advisory Database, PyPA, Go, RustSec and other ecosystem databases, under CC-BY 4.0 or CC0","CVE records: the CVE Program's CVE List (https://www.cve.org), under its terms of use (https://www.cve.org/Legal/TermsOfUse). CVE is a registered trademark of The MITRE Corporation; this product is not affiliated with the CVE Program."]}