CVE-2026-80857: fuse: wait for FR_FINISHED on abort_on_kill to prevent use-after-free
In the Linux kernel, the following vulnerability has been resolved:
fuse: wait for FRFINISHED on abortonkill to prevent use-after-free
The abortonkill path in requestwaitanswer() calls fuseabortconn() and returns without waiting for FRFINISHED. If fusedevdowrite() is concurrently processing the same request (FRLOCKED set), the caller frees req->args while it is still being accessed, causing a use-after-free.
Fix this by jumping to the existing waitevent(FRFINISHED) instead of returning early. The wait will not hang because fuseabortconn() ensures all requests are ended.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Compensating control
In request_wait_answer()'s abort_on_kill path, jump to the existing wait_event(FR_FINISHED) instead of returning early, so the caller does not free req->args while fuse_dev_do_write() may still be accessing it.
Event History
Frequently Asked Questions
Under what conditions can this race occur?
It requires the FUSE abort_on_kill path in request_wait_answer() to run while fuse_dev_do_write() is concurrently processing the same request and has set FR_LOCKED.
What happens when the race is triggered?
The request caller can free req->args before concurrent FUSE device write processing has finished accessing it, resulting in a use-after-free.
How does the fix prevent the issue?
Instead of returning immediately after fuse_abort_conn(), the corrected path waits for FR_FINISHED. fuse_abort_conn() ends outstanding requests, so this wait is not expected to hang.