CVE-2026-80860: fuse: fix race between interrupt and resend
In the Linux kernel, the following vulnerability has been resolved:
fuse: fix race between interrupt and resend
After commit f8fce75fedf7 ("fuse: clear intrentry in fuseresend and fuseremovependingreq") the WARNON(!listempty(&req->intrentry)) in fuserequestfree() still triggers due to the following race:
In requestwaitanswer() if (testbit(FRSENT, &req->flags)) -> returns true
In fusechanresend() clearbit(FRSENT, &req->flags)
In requestwaitanswer() queueinterrupt(req)
Fix by:
- move clearing FRSENT inside fpq->lock
- move setting FRPENDING inside fiq->lock
- recheck FRSENT after acquiring fiq->lock in fusedevqueueinterrupt()
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
linux kernel fuseto a version that resolves this vulnerability.Patch f8fce75fedf7 - Configuration
In fuse_chan_resend() and request_wait_answer(), clear FR_SENT via clear_bit(FR_SENT, &req->flags) as part of the race fix referenced by commit f8fce75fedf7.
fuse_chan_resend() / request_wait_answer() clear_bit(FR_SENT, &req->flags) = performed inside fuse_resend logic after fix - Configuration
In fuse_dev_queue_interrupt(), recheck FR_SENT after acquiring fiq->lock (per the described fix approach) to avoid stale FR_SENT state causing WARN_ON(!list_empty(&req->intr_entry)) to trigger.
fuse_dev_queue_interrupt() FR_SENT recheck after acquiring fiq->lock = recheck enabled after fiq->lock acquisition - Configuration
Move clearing of FR_SENT inside fpq->lock to synchronize interrupt vs resend behavior.
queue_interrupt path (FR_SENT handling) FR_SENT placement under locking (fpq->lock) = moved inside fpq->lock - Configuration
Move setting FR_PENDING inside fiq->lock to synchronize state transitions with interrupt handling.
queue_interrupt path (FR_PENDING handling) FR_PENDING placement under locking (fiq->lock) = moved inside fiq->lock
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Linux kernel systems that use FUSE may be affected when a FUSE request can be interrupted while it is being resent. The provided information does not identify specific kernel versions or configurations.
How can administrators identify that the race has occurred?
The race can cause the WARN_ON(!list_empty(&req->intr_entry)) check in fuse_request_free() to trigger. Kernel warning logs containing that condition are an indicator of the affected request-state race.
What condition triggers the problem?
It requires a race in which request_wait_answer() observes FR_SENT, fuse_chan_resend() clears FR_SENT, and request_wait_answer() then queues an interrupt. The fix synchronizes the relevant flag updates and rechecks FR_SENT while holding the interrupt-queue lock.