CVE-2025-40220 (GCVE-0-2025-40220)
Vulnerability from cvelistv5
Published
2025-12-04 14:50
Modified
2025-12-04 14:50
Severity ?
VLAI Severity ?
EPSS score ?
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:
"By closing the file descriptor before calling io_destroy, you pretty
much guarantee that the last put on the ioctx will be done in interrupt
context (during I/O completion).
Aha. AIO fgets a new struct file from the fd when it queues the ioctx.
The completion of the FUSE_WRITE command from userspace causes the fuse
server to call the AIO completion function. The completion puts the
struct file, queuing a delayed fput to the fuse server task. When the
fuse server task returns to userspace, it has to run the delayed fput,
which in the case of a fuseblk server, it does synchronously.
Sending the FUSE_RELEASE command sychronously from fuse server threads
is a bad idea because a client program can initiate enough simultaneous
AIOs such that all the fuse server threads end up in delayed_fput, and
now there aren't any threads left to handle the queued fuse commands.
Fix this by only using asynchronous fputs when closing files, and leave
a comment explaining why.
References
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| Linux | Linux |
Version: 5a18ec176c934ca1bc9dc61580a5e0e90a9b5733 Version: 5a18ec176c934ca1bc9dc61580a5e0e90a9b5733 Version: 5a18ec176c934ca1bc9dc61580a5e0e90a9b5733 Version: 5a18ec176c934ca1bc9dc61580a5e0e90a9b5733 Version: 5a18ec176c934ca1bc9dc61580a5e0e90a9b5733 Version: 5a18ec176c934ca1bc9dc61580a5e0e90a9b5733 Version: 5a18ec176c934ca1bc9dc61580a5e0e90a9b5733 Version: 9efe56738fecd591b5bf366a325440f9b457ebd6 Version: 5c46eb076e0a1b2c1769287cd6942e4594ade1b1 Version: 83e6726210d6c815ce044437106c738eda5ff6f6 Version: 23d154c71721fd0fa6199851078f32e6bd765664 Version: ca3edc920f5fd7d8ac040caaf109f925c24620a0 |
||
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"fs/fuse/file.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "548e1f2bac1d4df91a6138f26bb4ab00323fd948",
"status": "affected",
"version": "5a18ec176c934ca1bc9dc61580a5e0e90a9b5733",
"versionType": "git"
},
{
"lessThan": "cfd1aa3e2b71f3327cb373c45a897c9028c62b35",
"status": "affected",
"version": "5a18ec176c934ca1bc9dc61580a5e0e90a9b5733",
"versionType": "git"
},
{
"lessThan": "83b375c6efef69b1066ad2d79601221e7892745a",
"status": "affected",
"version": "5a18ec176c934ca1bc9dc61580a5e0e90a9b5733",
"versionType": "git"
},
{
"lessThan": "bfd17b6138df0122a95989457d8e18ce0b86165e",
"status": "affected",
"version": "5a18ec176c934ca1bc9dc61580a5e0e90a9b5733",
"versionType": "git"
},
{
"lessThan": "b26923512dbe57ae4917bafd31396d22a9d1691a",
"status": "affected",
"version": "5a18ec176c934ca1bc9dc61580a5e0e90a9b5733",
"versionType": "git"
},
{
"lessThan": "f19a1390af448d9e193c08e28ea5f727bf3c3049",
"status": "affected",
"version": "5a18ec176c934ca1bc9dc61580a5e0e90a9b5733",
"versionType": "git"
},
{
"lessThan": "26e5c67deb2e1f42a951f022fdf5b9f7eb747b01",
"status": "affected",
"version": "5a18ec176c934ca1bc9dc61580a5e0e90a9b5733",
"versionType": "git"
},
{
"status": "affected",
"version": "9efe56738fecd591b5bf366a325440f9b457ebd6",
"versionType": "git"
},
{
"status": "affected",
"version": "5c46eb076e0a1b2c1769287cd6942e4594ade1b1",
"versionType": "git"
},
{
"status": "affected",
"version": "83e6726210d6c815ce044437106c738eda5ff6f6",
"versionType": "git"
},
{
"status": "affected",
"version": "23d154c71721fd0fa6199851078f32e6bd765664",
"versionType": "git"
},
{
"status": "affected",
"version": "ca3edc920f5fd7d8ac040caaf109f925c24620a0",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"fs/fuse/file.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.38"
},
{
"lessThan": "2.6.38",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.246",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.196",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.158",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.115",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.54",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.17.*",
"status": "unaffected",
"version": "6.17.4",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.18",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.246",
"versionStartIncluding": "2.6.38",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.196",
"versionStartIncluding": "2.6.38",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.158",
"versionStartIncluding": "2.6.38",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.115",
"versionStartIncluding": "2.6.38",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.54",
"versionStartIncluding": "2.6.38",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.17.4",
"versionStartIncluding": "2.6.38",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.18",
"versionStartIncluding": "2.6.38",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "2.6.32.32",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "2.6.33.8",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "2.6.34.10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "2.6.35.12",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "2.6.37.3",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "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\u0027s 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\u0027t 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."
}
],
"providerMetadata": {
"dateUpdated": "2025-12-04T14:50:44.108Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/548e1f2bac1d4df91a6138f26bb4ab00323fd948"
},
{
"url": "https://git.kernel.org/stable/c/cfd1aa3e2b71f3327cb373c45a897c9028c62b35"
},
{
"url": "https://git.kernel.org/stable/c/83b375c6efef69b1066ad2d79601221e7892745a"
},
{
"url": "https://git.kernel.org/stable/c/bfd17b6138df0122a95989457d8e18ce0b86165e"
},
{
"url": "https://git.kernel.org/stable/c/b26923512dbe57ae4917bafd31396d22a9d1691a"
},
{
"url": "https://git.kernel.org/stable/c/f19a1390af448d9e193c08e28ea5f727bf3c3049"
},
{
"url": "https://git.kernel.org/stable/c/26e5c67deb2e1f42a951f022fdf5b9f7eb747b01"
}
],
"title": "fuse: fix livelock in synchronous file put from fuseblk workers",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2025-40220",
"datePublished": "2025-12-04T14:50:44.108Z",
"dateReserved": "2025-04-16T07:20:57.180Z",
"dateUpdated": "2025-12-04T14:50:44.108Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"nvd": "{\"cve\":{\"id\":\"CVE-2025-40220\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2025-12-04T15:15:58.033\",\"lastModified\":\"2025-12-04T17:15:08.283\",\"vulnStatus\":\"Awaiting Analysis\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"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\u0027s 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\u0027t 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.\"}],\"metrics\":{},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/26e5c67deb2e1f42a951f022fdf5b9f7eb747b01\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/548e1f2bac1d4df91a6138f26bb4ab00323fd948\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/83b375c6efef69b1066ad2d79601221e7892745a\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/b26923512dbe57ae4917bafd31396d22a9d1691a\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/bfd17b6138df0122a95989457d8e18ce0b86165e\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/cfd1aa3e2b71f3327cb373c45a897c9028c62b35\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/f19a1390af448d9e193c08e28ea5f727bf3c3049\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}]}}"
}
}
Loading…
Loading…
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.
Loading…
Loading…