Cloudanix VulnDB

CVE-2026-80860

None

CVSS

—

EPSS

0.2%

Published

Sep 4, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing flaw in Linux file handling for certain virtual drives could cause errors or crashes on machines doing lots of file operations.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Other
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Race condition between interrupt queuing and request resend paths in FUSE allows FR_SENT flag to be cleared after check but before interrupt handling, leaving intr_entry list non-empty when fuse_request_free is called and triggering WARN_ON.

Why it matters to the business

Systems relying on FUSE filesystems may experience kernel warnings, potential request handling corruption, or crashes under concurrent interrupt and resend workloads, increasing operational risk on servers or containers using virtual filesystems.

How an attack unfolds

An attacker with local access triggers FUSE request send and interrupt operations in rapid succession to exploit the unprotected flag manipulation window between request_wait_answer and fuse_chan_resend, causing inconsistent request state.

How to fix it

Apply the upstream Linux kernel fix that moves FR_SENT clearing inside fpq->lock, FR_PENDING setting inside fiq->lock, and adds FR_SENT recheck after acquiring fiq->lock; rebuild and reboot to patched kernel versions containing commit addressing the race.

How to confirm the fix worked

Verify kernel source contains the lock-protected flag operations and recheck logic; confirm absence of WARN_ON(!list_empty(&req->intr_entry)) in fuse_request_free under concurrent FUSE interrupt/resend tests; check dmesg for resolved warnings.

Typical attack path

  1. Mount a FUSE filesystem and issue I/O operations
  2. Trigger concurrent interrupt and resend paths via timing or workload
  3. Force clearing of FR_SENT outside protected sections
  4. Queue interrupt while request state is inconsistent
  5. Reach fuse_request_free with non-empty intr_entry list

How to detect it

Search kernel logs and dmesg for the fuse_request_free WARN_ON message or related FUSE request state warnings; review audit logs for unusual FUSE mount activity coinciding with crashes or high interrupt rates.

  • WARN_ON(!list_empty(&req->intr_entry))
  • fuse_request_free
  • fuse_chan_resend
  • request_wait_answer

What your security team should do

  • Prioritize kernel updates for all systems using FUSE within 30 days given publication age
  • Audit workloads for heavy FUSE usage and schedule staged rollouts
  • Enable kernel panic on warnings temporarily during validation to surface latent issues
  • Monitor upstream stable branches for backports to distribution kernels

The record

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()

Affected packages

Ecosystem Package Introduced Fixed