CVE-2026-80859: Linux Kernel FUSE Race Condition Vulnerability

CVE-2026-80859 Overview

CVE-2026-80859 is a race condition in the Linux kernel's Filesystem in Userspace (FUSE) subsystem. The flaw stems from a missing read memory barrier in fuse_block_alloc() when checking whether the io-uring queues are ready. Without the paired smp_rmb(), a CPU can observe fch->initialized=1 while still seeing fch->io_uring=0, bypassing the check that blocks request allocation until io-uring queues are initialized.

Critical Impact
The race can reintroduce a lock-order inversion deadlock that commit 3393ff964e0f was designed to prevent, leading to kernel hangs on affected FUSE mounts.

Affected Products

Linux kernel versions containing the FUSE io-uring implementation prior to the fixing commits
Distributions shipping stable kernels affected by commits 8974575, dd9c835, and edb310b
Systems using FUSE filesystems with io-uring enabled

Discovery Timeline

2026-09-04 - CVE-2026-80859 published to NVD
2026-09-11 - Last updated in NVD database

Technical Details for CVE-2026-80859

Vulnerability Analysis

The vulnerability lives in the FUSE subsystem's io-uring readiness check. The function fuse_chan_set_initialized() writes fch->io_uring before fch->initialized and inserts an smp_wmb() write barrier between them. This ordering guarantees remote CPUs observe io_uring populated before initialized becomes true.

The consuming function fuse_block_alloc() performs the mirrored reads: it loads fch->initialized first, then fch->io_uring. However, it lacks a matching smp_rmb() between the two loads. On weakly ordered architectures, the CPU can reorder these loads, producing a state where initialized appears true while io_uring still reads as zero or NULL.

When this reordering occurs, fuse_block_alloc() skips the guard that blocks request allocation until io-uring queues are ready. Requests then proceed into a code path that acquires locks in an order incompatible with the initialization path, reintroducing the lock-order inversion deadlock previously fixed by commit 3393ff964e0f.

Root Cause

The root cause is an asymmetric memory barrier pairing. Producer code uses smp_wmb() to order two stores, but consumer code omits the corresponding smp_rmb() between the two dependent loads. Memory barrier semantics on the Linux kernel require both sides of the pairing to enforce ordering across CPUs.

Attack Vector

The issue triggers under concurrent FUSE channel initialization and request allocation. A local process interacting with a FUSE mount that uses io-uring can race with the initialization path. The observable impact is a system-wide deadlock on the affected FUSE channel rather than memory corruption or privilege escalation.

The vulnerability manifests only on architectures with weak memory ordering, such as arm64 or POWER. Refer to the upstream commits 8974575898cd7a4c818088f102b2e7a0286d3302, dd9c835709f4bb3e4256eea7573e4e6e18f956de, and edb310bc27f0ad83e7fd558a3caf1a94ca511654 for the exact source-level fix.

Detection Methods for CVE-2026-80859

Indicators of Compromise

Kernel soft-lockup or hung task warnings referencing fuse_block_alloc or FUSE io-uring code paths in dmesg output.
Processes stuck in uninterruptible sleep (D state) waiting on a FUSE mount that uses io-uring.
Repeated stack traces showing lock acquisition inside FUSE request allocation paired with io-uring queue setup.

Detection Strategies

Inventory running kernel versions across Linux hosts and compare against the upstream stable trees that received commits 8974575, dd9c835, and edb310b.
Identify workloads mounting FUSE filesystems with io-uring enabled, since only those code paths exercise the racy check.
Monitor kernel logs for hung task detection warnings and correlate them with FUSE activity.

Monitoring Recommendations

Enable kernel.hung_task_timeout_secs and forward hung task warnings to centralized logging for review.
Track FUSE channel creation events and io-uring initialization messages through the audit subsystem.
Alert on repeated D-state process accumulation on hosts running FUSE-based storage or containerization workloads.

How to Mitigate CVE-2026-80859

Immediate Actions Required

Apply vendor-supplied kernel updates that include the smp_rmb() addition from the referenced upstream commits.
Reboot affected systems after patching to activate the fixed kernel, since the fix cannot be applied via live patching for all distributions.
Prioritize patching on weakly ordered architectures such as arm64 and POWER where the race is most likely to be observed.

Patch Information

The fix adds an smp_rmb() barrier in fuse_block_alloc() to pair with the existing smp_wmb() in fuse_chan_set_initialized(). Upstream stable kernel commits are available at Kernel Git Commit 8974575, Kernel Git Commit dd9c835, and Kernel Git Commit edb310b. Consult your distribution's security tracker for backported package builds.

Workarounds

Disable io-uring support for FUSE mounts where the workload does not require it, avoiding the affected code path entirely.
Restrict use of FUSE filesystems on multi-tenant hosts running weakly ordered architectures until a patched kernel is deployed.
Where deadlocks are observed, unmount and remount affected FUSE filesystems to restore service while patching is scheduled.

bash

# Verify running kernel and check for the fix commits in your distribution
uname -r
rpm -q --changelog kernel | grep -E '8974575|dd9c835|edb310b'
# Debian/Ubuntu equivalent
apt changelog linux-image-$(uname -r) | grep -E '8974575|dd9c835|edb310b'