CVE-2026-68095: Linux Kernel Race Condition Vulnerability

CVE-2026-68095 Overview

CVE-2026-68095 is a race condition in the Linux kernel fuse-uring subsystem. The flaw occurs between FUSE ring entry registration through io_uring and connection abortion during filesystem teardown. When the two operations interleave, the abort path observes a zero queue_refs count and skips the abort logic, while the registration path subsequently increments the reference. The teardown thread then waits indefinitely for queue_refs to reach zero, leaving the mount thread hung in an unkillable state and leaking the ring, queue, and entry allocations. The vulnerability was fixed in mainline Linux via commits 2cd9454, 3bca702, and 952b5d3.

Critical Impact
Local users triggering concurrent FUSE ring registration and connection abortion can cause the unmount thread to hang indefinitely in an unkillable state, leaking kernel memory and creating a persistent denial-of-service condition.

Affected Products

Linux kernel versions containing the fuse-uring subsystem prior to the fix
Systems using FUSE (Filesystem in Userspace) with io_uring acceleration
Distributions shipping vulnerable Linux kernel builds

Discovery Timeline

2026-08-10 - CVE-2026-68095 published to NVD
2026-08-10 - Last updated in NVD database

Technical Details for CVE-2026-68095

Vulnerability Analysis

The vulnerability is a race condition [CWE-362] in the FUSE io_uring integration. Two threads interact with shared state without adequate synchronization between the moment a ring entry is allocated and the moment it grabs a reference count on its queue.

Thread A enters io_uring_enter, registers a submission queue entry, and reaches fuse_uring_create_ring_ent. It allocates the entry but has not yet incremented queue_refs. Thread B concurrently invokes fuse_conn_destroy(), which calls fuse_chan_abort() and then fuse_uring_abort(). Because queue_refs is still zero, the abort function returns as a no-op.

Thread A then grabs the queue reference, raising queue_refs to one, and completes the remainder of fuse_uring_do_register(). Thread B proceeds to fuse_chan_wait_aborted(), which invokes wait_event(ring->stop_waitq, atomic_read(&ring->queue_refs) == 0). Nothing in the system decrements queue_refs or wakes stop_waitq, so the abort thread blocks forever.

Root Cause

The root cause is missing atomicity between reference acquisition and the connection state check. The registration path did not verify fch->connected under fch->lock after grabbing the queue reference, allowing the abort path to miss the newly registered entry.

Attack Vector

A local user with permission to mount FUSE filesystems and issue io_uring calls can trigger the race by concurrently registering FUSE ring entries and aborting the FUSE connection. Successful exploitation produces an unkillable kernel thread and leaks the associated ring, queue, and entry structures, degrading system availability over time.

The fix, applied across the referenced kernel commits, adds a check of fch->connected under fch->lock after the entry acquires its queue reference. If the connection is no longer connected, the code releases the reference and wakes stop_waitq; otherwise the async teardown worker is guaranteed to clean up the entry.

Detection Methods for CVE-2026-68095

Indicators of Compromise

Unmount or filesystem teardown processes stuck in uninterruptible sleep (D state) with stack traces referencing fuse_chan_wait_aborted or wait_event on stop_waitq.
Growing kernel memory attributable to leaked FUSE ring, queue, and entry allocations following abnormal FUSE client termination.
hung_task warnings in dmesg referencing FUSE or fuse_uring symbols.

Detection Strategies

Monitor /proc/<pid>/stack for FUSE-related processes stuck in fuse_chan_wait_aborted after unmount attempts.
Enable the kernel hung_task_timeout_secs watchdog and forward hung_task messages to a central log store for correlation.
Track kernel SLAB/SLUB allocations for FUSE structures over time to identify leak patterns.

Monitoring Recommendations

Correlate FUSE mount/unmount events with io_uring_setup and io_uring_enter syscall telemetry on the same PID and cgroup.
Alert on any process transitioning to D state for longer than the site-defined threshold with FUSE symbols in its kernel stack.
Aggregate kernel log events referencing fuse_uring from all hosts to identify systems still running unpatched kernels.

How to Mitigate CVE-2026-68095

Immediate Actions Required

Inventory Linux hosts running kernels with fuse-uring support and identify those without commits 2cd9454, 3bca702, or 952b5d3 applied.
Restrict which users and containers can mount FUSE filesystems using fusermount permissions and namespace controls until patches are deployed.
On systems where FUSE io_uring acceleration is not required, disable it in FUSE client configuration to remove exposure.

Patch Information

The fix is available in the upstream Linux kernel via commits Kernel Git Commit 2cd9454, Kernel Git Commit 3bca702, and Kernel Git Commit 952b5d3. The patch adds a fch->connected check under fch->lock after the ring entry grabs a queue reference, ensuring the abort path and registration path cannot both miss the entry. Apply distribution-provided kernel updates that incorporate these commits and reboot affected hosts.

Workarounds

Limit io_uring availability via sysctl kernel.io_uring_disabled=2 where FUSE io_uring is not required by workloads.
Constrain FUSE mounting to trusted users only by tightening permissions on /usr/bin/fusermount3 and disallowing unprivileged user namespaces where feasible.
Reboot hosts that already exhibit hung FUSE teardown threads, since the leaked structures cannot be reclaimed without a kernel restart.

bash

# Configuration example: restrict io_uring and identify vulnerable kernels
# Check current kernel version
uname -r

# Temporarily disable io_uring for non-privileged processes
sysctl -w kernel.io_uring_disabled=2

# Persist across reboots
echo 'kernel.io_uring_disabled = 2' >> /etc/sysctl.d/99-cve-2026-68095.conf

# Identify hung FUSE teardown threads
for pid in $(ps -eo pid,stat,comm | awk '$2 ~ /D/ {print $1}'); do
  grep -l fuse_chan_wait_aborted /proc/$pid/stack 2>/dev/null
done