CVE-2025-40220 json
fuse: fix livelock in synchronous file put from fuseblk workers
published 2025-12-04 11 mo ago modified 2026-10-19 20 d ago also EUVD-2025-201183
- cvss
- —
- not scored
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- 0.2%
- EPSS 0.2% chance of exploitation in 30 days, percentile 10%
- public exploits
- 0
- none known
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.
Patch / fix
- Linux Linux 2.6.33, 2.6.34, 2.6.35, 2.6.36, 2.6.38, 5.10.246, 5.15.196, 6.1.158, 6.6.115, 6.12.54, 6.17.4, 6.18
- linux Debian 12 6.1.158-1
- linux Debian 13 6.12.57-1
- linux Debian 14 6.17.6-1
debian advisories DEBIAN-CVE-2025-40220
- linux Ubuntu 22.04 LTS 5.15.0-170.180
- linux Ubuntu 24.04 LTS 6.8.0-106.106
- linux Ubuntu 25.10 6.17.0-14.14
- linux-aws Ubuntu 22.04 LTS 5.15.0-1100.107
- linux-aws Ubuntu 24.04 LTS 6.8.0-1050.53
- linux-aws Ubuntu 25.10 6.17.0-1007.7
- linux-gcp Ubuntu 22.04 LTS 5.15.0-1100.109
- linux-gcp Ubuntu 24.04 LTS 6.8.0-1052.55
ubuntu advisories UBUNTU-CVE-2025-40220
Ubuntu security data © Canonical Ltd., from https://github.com/canonical/ubuntu-security-notices via OSV; changed: normalised to fixed package versions per release. CC BY-SA 4.0
- kernel-rt Linux Micro 6.1, Linux Micro 6.0 6.4.0-40.1
- kernel-source-rt Linux Micro 6.1, Linux Micro 6.0 6.4.0-40.1
- kernel-64kb SLES 15 SP4-LTSS, SLE High Performance Computing 15 SP4-LTSS, SLE High Performance Computing 15 SP4-ESPOS 5.14.21-150400.24.194.1
- kernel-syms SLES for SAP 15 SP4, SLES 15 SP4-LTSS, SLE High Performance Computing 15 SP4-LTSS +1 more 5.14.21-150400.24.194.1
- kernel-source SLES for SAP 15 SP4, SLES 15 SP4-LTSS, SLE High Performance Computing 15 SP4-LTSS +1 more 5.14.21-150400.24.194.1
- kernel-default SLES for SAP 15 SP4, SLES 15 SP4-LTSS, SLE Micro 5.4 +5 more 5.14.21-150400.24.194.1
- kernel-obs-build SLES for SAP 15 SP4, SLES 15 SP4-LTSS, SLE High Performance Computing 15 SP4-LTSS +1 more 5.14.21-150400.24.194.1
- kernel-default-base SLES for SAP 15 SP4, SLES 15 SP4-LTSS, SLE Micro 5.4 +3 more 5.14.21-150400.24.194.1.150400.24.98.3
suse advisories SUSE-SU-2026:1078-1SUSE-SU-2026:20845-1SUSE-SU-2026:20876-1SUSE-SU-2026:0617-1SUSE-SU-2026:20477-1SUSE-SU-2026:20498-1
- kernel-rt openSUSE Leap 16.0 6.12.0-160000.9.1
- dtb-aarch64 openSUSE Leap 16.0 6.12.0-160000.9.1
- kernel-64kb openSUSE Leap 16.0 6.12.0-160000.9.1
- kernel-syms openSUSE Leap 16.0 6.12.0-160000.9.1
- kernel-azure openSUSE Leap 16.0 6.12.0-160000.9.1
- kernel-obs-qa openSUSE Leap 16.0 6.12.0-160000.9.1
- kernel-source openSUSE Leap 16.0 6.12.0-160000.9.1
- kernel-default openSUSE Leap 16.0 6.12.0-160000.9.1
opensuse advisories openSUSE-SU-2026:20145-1
- git.kernel.org/stable/c/548e1f2bac1d4df91a6138f26bb4ab00323fd948 commit
- git.kernel.org/stable/c/cfd1aa3e2b71f3327cb373c45a897c9028c62b35 commit
- git.kernel.org/stable/c/83b375c6efef69b1066ad2d79601221e7892745a commit
- git.kernel.org/stable/c/bfd17b6138df0122a95989457d8e18ce0b86165e commit
- git.kernel.org/stable/c/b26923512dbe57ae4917bafd31396d22a9d1691a commit
- git.kernel.org/stable/c/f19a1390af448d9e193c08e28ea5f727bf3c3049 commit
- git.kernel.org/stable/c/26e5c67deb2e1f42a951f022fdf5b9f7eb747b01 commit
Vendor advisories
What the vendors themselves say about their products: affected, fixed or not affected, and what to do.
red hat product security vex CVE-2025-40220 updated cvss 4.7
kernel: fuse: fix livelock in synchronous file put from fuseblk workers
-
Red Hat Enterprise Linux 6 perf, kernel, python-perf, kernel-kdump, kernel-firmware, kernel-bootwrapper, +1 moreaffected: no fix planned “Out of support scope”
-
Red Hat Enterprise Linux 7 perf, kernel, bpftool, kernel-rt, python-perf, kernel-kdump, +8 more Red Hat Enterprise Linux 8 perf, kernel, bpftool, kernel-rt, kernel-core, kernel-tools, +29 more Red Hat Enterprise Linux 9 rv, perf, rtla, kernel, bpftool, libperf, +83 more Red Hat Enterprise Linux 10 kernelaffected: no fix available “Fix deferred”
Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf
Exploit prediction
0.21% chance of exploitation in the next 30 days, higher than 10% of all scored CVEs (FIRST EPSS, 2026-11-08).
Affected products
- Linux Linux
Classification
- Technology feeds
References
- git.kernel.org /stable/c/548e1f2bac1d4df91a6138f26bb4ab00323fd948
- git.kernel.org /stable/c/cfd1aa3e2b71f3327cb373c45a897c9028c62b35
- git.kernel.org /stable/c/83b375c6efef69b1066ad2d79601221e7892745a
- git.kernel.org /stable/c/bfd17b6138df0122a95989457d8e18ce0b86165e
- git.kernel.org /stable/c/b26923512dbe57ae4917bafd31396d22a9d1691a
- git.kernel.org /stable/c/f19a1390af448d9e193c08e28ea5f727bf3c3049
- git.kernel.org /stable/c/26e5c67deb2e1f42a951f022fdf5b9f7eb747b01
Sources
- CVE List CVE-2025-40220
- NVD CVE-2025-40220
Fencer Vulns keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.