CVE-2026-64265: fuse: clear intr_entry in fuse_resend and fuse_remove_pending_req
In the Linux kernel, the following vulnerability has been resolved:
fuse: clear intrentry in fuseresend and fuseremovependingreq
When fuseresend() moves a request from fpq->processing back to fiq->pending, it sets FRPENDING and clears FRSENT but does not remove the requests intrentry from fiq->interrupts. If the request had FRINTERRUPTED set from a prior signal, intrentry remains dangling on fiq->interrupts. When the requesting task then receives a fatal signal, fuseremovependingreq() sees FRPENDING=1, removes the request from fiq->pending and frees it via the refcount path, also without cleaning intrentry. The stale intrentry causes use-after-free when fusereadinterrupt() iterates fiq->interrupts: - listdelinit(&req->intrentry) -> UAF write on freed slab - req->in.h.unique -> UAF read, data leaked to userspace
Remove intrentry from fiq->interrupts in fuseresend() for interrupted requests before they are placed back on fiq->pending.
Add a WARNON if the intrentry is not empty on request destruction.
Affected Software
Event History
Frequently Asked Questions
What access does an attacker need to exploit this issue?
The CVSS vector identifies this as a local attack requiring low privileges. It does not require user interaction.
What conditions trigger the use-after-free?
A FUSE request must have been interrupted, then moved by fuse_resend() from processing back to pending while its interrupt-list entry remains linked. If the requesting task subsequently receives a fatal signal and the interrupt list is read, the stale entry can be dereferenced after the request is freed.
What is the potential impact of successful exploitation?
The stale interrupt entry can cause a use-after-free write when it is removed and a use-after-free read of the request unique value, which can leak data to userspace. The CVSS assessment rates confidentiality, integrity, and availability impact as high.