{"id":"AZL-71290","summary":"CVE-2025-40220 affecting package kernel for versions less than 6.6.117.1-1","details":"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[\u003c0\u003e] request_wait_answer+0x1fe/0x2a0 [fuse]\n[\u003c0\u003e] __fuse_simple_request+0xd3/0x2b0 [fuse]\n[\u003c0\u003e] fuse_do_getattr+0xfc/0x1f0 [fuse]\n[\u003c0\u003e] fuse_file_read_iter+0xbe/0x1c0 [fuse]\n[\u003c0\u003e] aio_read+0x130/0x1e0\n[\u003c0\u003e] io_submit_one+0x542/0x860\n[\u003c0\u003e] __x64_sys_io_submit+0x98/0x1a0\n[\u003c0\u003e] do_syscall_64+0x37/0xf0\n[\u003c0\u003e] 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[\u003c0\u003e] request_wait_answer+0x1fe/0x2a0 [fuse]\n[\u003c0\u003e] __fuse_simple_request+0xd3/0x2b0 [fuse]\n[\u003c0\u003e] fuse_file_put+0x9a/0xd0 [fuse]\n[\u003c0\u003e] fuse_release+0x36/0x50 [fuse]\n[\u003c0\u003e] __fput+0xec/0x2b0\n[\u003c0\u003e] task_work_run+0x55/0x90\n[\u003c0\u003e] syscall_exit_to_user_mode+0xe9/0x100\n[\u003c0\u003e] do_syscall_64+0x43/0xf0\n[\u003c0\u003e] 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.","modified":"2026-04-01T05:21:45.189679Z","published":"2025-12-04T15:15:58Z","upstream":["CVE-2025-40220"],"references":[{"type":"WEB","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40220"}],"affected":[{"package":{"name":"kernel","ecosystem":"Azure Linux:3","purl":"pkg:rpm/azure-linux/kernel"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.117.1-1"}]}],"database_specific":{"source":"https://github.com/microsoft/AzureLinuxVulnerabilityData/blob/main/osv/AZL-71290.json"}}],"schema_version":"1.7.5"}