fuse: fix livelock in synchronous file put from fuseblk workers
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: "B
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 5.10.246, 5.15.196, 6.1.158, 6.12.54, 6.17.4, 6.6.115
- CVEs
- CVE-2025-40220
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 3 Nov 2026, 07:43 UTC · Revision 1
Source evidence
fuse: fix livelock in synchronous file put from fuseblk workers
core-osv · Original sourcePublished 4 Dec 2025, 14:50 UTC
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: "B
osv:CVE-2025-40220
Kernel
Fixed versions: 5.10.246, 5.15.196, 6.1.158, 6.6.115, 6.12.54, 6.17.4
Complete source record
{
"id": "efb7ae4f01e478744225a2bffe688cc1fb8efe642527e69171ec688d6a193a04",
"url": "https://osv.dev/vulnerability/CVE-2025-40220",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "fuse: fix livelock in synchronous file put from fuseblk workers",
"summary": "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: \"B",
"evidence": "osv:CVE-2025-40220",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "5.10.246",
"evidence": "/affected/1/ranges"
},
{
"value": "5.15.196",
"evidence": "/affected/1/ranges"
},
{
"value": "6.1.158",
"evidence": "/affected/1/ranges"
},
{
"value": "6.6.115",
"evidence": "/affected/1/ranges"
},
{
"value": "6.12.54",
"evidence": "/affected/1/ranges"
},
{
"value": "6.17.4",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "unknown",
"structured": {
"id": "CVE-2025-40220",
"aliases": [
"CVE-2025-40220"
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "5a18ec176c934ca1bc9dc61580a5e0e90a9b5733"
},
{
"fixed": "548e1f2bac1d4df91a6138f26bb4ab00323fd948"
},
{
"fixed": "cfd1aa3e2b71f3327cb373c45a897c9028c62b35"
},
{
"fixed": "83b375c6efef69b1066ad2d79601221e7892745a"
},
{
"fixed": "bfd17b6138df0122a95989457d8e18ce0b86165e"
},
{
"fixed": "b26923512dbe57ae4917bafd31396d22a9d1691a"
},
{
"fixed": "f19a1390af448d9e193c08e28ea5f727bf3c3049"
},
{
"fixed": "26e5c67deb2e1f42a951f022fdf5b9f7eb747b01"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "2.6.32.32"
},
{
"fixed": "2.6.33"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "2.6.33.8"
},
{
"fixed": "2.6.34"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "2.6.34.10"
},
{
"fixed": "2.6.35"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "2.6.35.12"
},
{
"fixed": "2.6.36"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "2.6.37.3"
},
{
"fixed": "2.6.38"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "9efe56738fecd591b5bf366a325440f9b457ebd6"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "5c46eb076e0a1b2c1769287cd6942e4594ade1b1"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "83e6726210d6c815ce044437106c738eda5ff6f6"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "23d154c71721fd0fa6199851078f32e6bd765664"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "ca3edc920f5fd7d8ac040caaf109f925c24620a0"
}
]
}
],
"versions": [
"v2.6.32.71",
"v2.6.32.70",
"v2.6.32.69",
"v2.6.32.68",
"v2.6.32.67",
"v2.6.32.66",
"v2.6.32.65",
"v2.6.32.64",
"v2.6.32.63",
"v2.6.32.62",
"v2.6.32.61",
"v2.6.32.60",
"v2.6.32.59",
"v2.6.32.58",
"v2.6.32.57",
"v2.6.32.56",
"v2.6.32.55",
"v2.6.32.54",
"v2.6.32.53",
"v2.6.32.52",
"v2.6.32.51",
"v2.6.32.50",
"v2.6.32.49",
"v2.6.32.48",
"v2.6.32.47",
"v2.6.32.46",
"v2.6.32.45",
"v2.6.32.44",
"v2.6.32.43",
"v2.6.32.42",
"v2.6.32.41",
"v2.6.32.40",
"v2.6.32.39",
"v2.6.32.38",
"v2.6.32.37",
"v2.6.32.36",
"v2.6.32.35",
"v2.6.32.34",
"v2.6.32.33",
"v2.6.32.32",
"v2.6.33.20",
"v2.6.33.19",
"v2.6.33.18",
"v2.6.33.17",
"v2.6.33.16",
"v2.6.33.15",
"v2.6.33.14",
"v2.6.33.13",
"v2.6.33.12",
"v2.6.33.11",
"v2.6.33.10",
"v2.6.33.9",
"v2.6.33.8",
"v2.6.34.15",
"v2.6.34.14",
"v2.6.34.13",
"v2.6.34.12",
"v2.6.34.11",
"v2.6.34.10",
"v2.6.35.14",
"v2.6.35.13",
"v2.6.35.12",
"v2.6.37.6",
"v2.6.37.5",
"v2.6.37.4",
"v2.6.37.3"
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2025-40220.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "2.6.38"
},
{
"fixed": "5.10.246"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.11.0"
},
{
"fixed": "5.15.196"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.16.0"
},
{
"fixed": "6.1.158"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.2.0"
},
{
"fixed": "6.6.115"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.7.0"
},
{
"fixed": "6.12.54"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.13.0"
},
{
"fixed": "6.17.4"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2025-40220.json"
}
}
],
"modified": "2026-10-28T02:30:26.662955945Z",
"provider": "osv",
"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",
"https://git.kernel.org/stable/c/cfd1aa3e2b71f3327cb373c45a897c9028c62b35",
"https://git.kernel.org/stable/c/f19a1390af448d9e193c08e28ea5f727bf3c3049",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/40xxx/CVE-2025-40220.json",
"https://nvd.nist.gov/vuln/detail/CVE-2025-40220",
"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
],
"provider_metadata": {
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/40xxx/CVE-2025-40220.json"
}
},
"related_cves": [
{
"value": "CVE-2025-40220",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": null
},
"source_id": "core-osv",
"document_id": 493462,
"published_at": "2025-12-04T14:50:44.108+00:00"
}