CVE-2026-80860 in Linux
Summary
by MITRE • 09/04/2026
In the Linux kernel, the following vulnerability has been resolved:
fuse: fix race between interrupt and resend
After commit f8fce75fedf7 ("fuse: clear intr_entry in fuse_resend and fuse_remove_pending_req") the WARN_ON(!list_empty(&req->intr_entry)) in fuse_request_free() still triggers due to the following race:
In request_wait_answer() if (test_bit(FR_SENT, &req->flags)) -> returns true
In fuse_chan_resend() clear_bit(FR_SENT, &req->flags)
In request_wait_answer() queue_interrupt(req)
Fix by:
- move clearing FR_SENT inside fpq->lock
- move setting FR_PENDING inside fiq->lock
- recheck FR_SENT after acquiring fiq->lock in fuse_dev_queue_interrupt()
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/05/2026
The Linux kernel's FUSE (Filesystem in Userspace) subsystem contains a race condition vulnerability located within the request handling and interrupt management logic. This flaw was introduced following commit f8fce75fedf7, which aimed to clear the intr_entry field during fuse_resend and fuse_remove_pending_req operations. Despite this remediation attempt, a specific concurrency issue persists that triggers a WARN_ON assertion failure in the fuse_request_free function. The core of the vulnerability lies in an unsafe sequence of flag checks and modifications across multiple execution contexts involving request waiting channels and interrupt queuing mechanisms. Specifically, the race occurs when one thread determines that a file system request has been sent by checking the FR_SENT flag within the request_wait_answer routine, while another concurrent thread executing fuse_chan_resend simultaneously clears this same flag. This lack of atomicity allows the first thread to proceed under the false assumption that the request is still in flight and subsequently attempts to queue an interrupt for it via queue_interrupt.
This race condition results in a state inconsistency where the system believes an interrupt entry exists or should be managed, but the underlying data structures have been altered by the concurrent resend operation. The failure manifests as a kernel warning because the list associated with intr_entry is not empty when fuse_request_free attempts to clean up resources, indicating that cleanup logic was invoked on a request structure that still holds pending references due to the interrupted state transition. Such race conditions in kernel space can lead to unpredictable behavior, including potential use-after-free scenarios if memory management routines proceed based on stale assumptions about object lifecycles. Although currently observed as a warning trigger, similar concurrency flaws in critical subsystems like FUSE often serve as precursors to more severe exploitation vectors involving privilege escalation or denial of service through kernel panic conditions.
From a vulnerability classification perspective, this issue aligns with CWE-362, which describes concurrent execution using shared resources with improper synchronization. The lack of proper locking around the modification and verification of request flags allows multiple threads to interfere with each other's state transitions. Furthermore, in the context of the MITRE ATT&CK framework for enterprise security, this type of flaw relates to techniques involving exploitation of race conditions within operating system components. Attackers who can trigger high volumes of FUSE requests or manipulate channel resending behaviors might exploit this timing window to destabilize the kernel environment or potentially bypass certain integrity checks if the state corruption extends beyond simple flag management into memory allocation boundaries.
The resolution involves restructuring the locking strategy to ensure atomicity in critical sections where request flags are inspected and modified. The fix mandates moving the clearing of the FR_SENT flag inside the fpq lock, thereby serializing access to this specific status bit during resend operations. Additionally, setting the FR_PENDING flag is moved within the fiq lock context to prevent concurrent modifications from different threads. Crucially, the fuse_dev_queue_interrupt function now rechecks the FR_SENT state after acquiring the fiq lock. This three-part adjustment ensures that any decision to queue an interrupt is made only when the system has a consistent and up-to-date view of the request's transmission status, effectively eliminating the window where stale flag values could lead to incorrect resource management actions.
To mitigate this vulnerability in deployed systems, administrators should ensure that Linux kernels are updated with patches addressing this specific FUSE race condition. Since this is an upstream kernel fix, distribution-specific security updates must be applied promptly. For environments relying heavily on FUSE-based storage solutions such as cloud block storage or network file systems, monitoring for kernel warning logs related to fuse_request_free can provide early indicators of exploitation attempts or stress conditions that trigger the race. Regular auditing of system stability under high-concurrency workloads is also recommended to detect any residual instability in request handling paths before they escalate into critical failures.