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.
- Compensating control
In the FUSE abort_on_kill path, ensure the request waits for FR_FINISHED (e.g., jump to wait_event(FR_FINISHED) in request_wait_answer / before returning) so fuse_abort_conn() does not return early and trigger a use-after-free when req->args is freed while still accessed.
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.