GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel FUSE: race between request interrupt and resend leaves a request queued on the interrupt list

UnscoredCVE-2026-80860Kernel, userspace & hypervisorcurated

Impact

request_wait_answer() can test FR_SENT and see it set at the moment fuse_chan_resend() clears it, then queue an interrupt for a request that is being resent. The request ends up freed with a non-empty intr_entry, which is what the WARN_ON in fuse_request_free() catches - so the observable symptom in the record is a kernel warning, but the underlying state is the interrupt list being manipulated by two paths at once. The fix moves the FR_SENT clear under fpq->lock, the FR_PENDING set under fiq->lock, and rechecks FR_SENT after taking fiq->lock. It matters on nodes whose FUSE daemon resends requests - server restart or failover of a fuse-backed container image, dataset or object-store mount. Note this is a follow-up to an earlier incomplete fix (commit f8fce75fedf7), so a kernel carrying only that commit is still affected.

Who can reach it

Local: requires a FUSE server that resends in-flight requests plus interrupt delivery on the same request, so it is driven by the filesystem daemon and its clients rather than by an arbitrary remote party. No authentication beyond normal node access.

What to do

Update to a stable kernel containing commit 26fbe4bc or ed9c881f and reboot each node. The record names no fixed release number, and there is no configuration-level mitigation other than not exercising FUSE request resend.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.