CVE-2026-64265

In the Linux kernel, the following vulnerability has been resolved:

fuse: clear intr_entry in fuse_resend and fuse_remove_pending_req

When fuse_resend() moves a request from fpq->processing back to fiq->pending, it sets FR_PENDING and clears FR_SENT but does not remove the requests intr_entry from fiq->interrupts. If the request had FR_INTERRUPTED set from a prior signal, intr_entry remains dangling on fiq->interrupts. When the requesting task then receives a fatal signal, fuse_remove_pending_req() sees FR_PENDING=1, removes the request from fiq->pending and frees it via the refcount path, also without cleaning intr_entry. The stale intr_entry causes use-after-free when fuse_read_interrupt() iterates fiq->interrupts:

• list_del_init(&req->intr_entry) -> UAF write on freed slab
• req->in.h.unique -> UAF read, data leaked to userspace

Remove intr_entry from fiq->interrupts in fuse_resend() for interrupted requests before they are placed back on fiq->pending.

Add a WARN_ON if the intr_entry is not empty on request destruction.

Weakness

The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory “belongs” to the code that operates on the new pointer.

Affected Software

Potential Mitigations

References

• https://git.kernel.org/stable/c/1d8ecd0cd696a5df0b2f72046a4ccee5d2a8ec2c
• https://git.kernel.org/stable/c/7366e6f4d2b4c7002b13fb01219e83679dad4127
• https://git.kernel.org/stable/c/893479015cb6442fd389d3b553ab3036c9541715
• https://git.kernel.org/stable/c/f8fce75fedf73ac72aa09163deb8f4291fdcaad2