Description
In the Linux kernel, the following vulnerability has been resolved:

fuse-uring: fix race between registration and connection abortion

This fixes this race:
- thread a: io_uring_enter -> register sqe ->
fuse_uring_create_ring_ent -> allocate ent but doesn't grab queue_ref
yet
- thread b: fuse_conn_destroy() -> fuse_chan_abort() ->
fuse_uring_abort() is a no-op due to queue ref being 0
- thread a: grabs the queue_ref, queue_ref is now 1, rest of
fuse_uring_do_register() logic executes
- thread b: fuse_chan_abort() returns, fuse_chan_wait_aborted() now runs
and calls
"wait_event(ring->stop_waitq, atomic_read(&ring->queue_refs) == 0);"
The abort/unmount thread will hang indefinitely in unkillable state as
nothing will decrement queue_refs or wake stop_waitq, and the ring,
queue, and ent are leaked.

Fix this by checking fch->connected under fch->lock after the created
ent has grabbed a ref count on the queue. This ensures that in the
scenario above, it is guaranteed that we either release the queue ref
and wake up stop_waitq (in case fuse_chan_wait_aborted() is already
waiting) in fuse_uring_do_register() when we detect !fch->connected, or
if the connection is aborted after the check, it is guaranteed that the
async teardown worker will be running in the background cleaning up ents
and decrementing the ent's ref on the queue, which will unblock the
eventual queue and ring teardown.
Published: 2026-08-10
Score: n/a
EPSS: n/a
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The vulnerability is a race condition in the Linux kernel’s fuse-uring subsystem. Concurrent execution of a ring registration and a connection abortion can cause the unmount thread to wait forever, leading to an indefinite hang and leaking internal structures. The flaw results in a denial‑of‑service scenario but does not directly provide code execution or data exfiltration. The weakness can be classified as a race condition (CWE-362).

Affected Systems

All Linux kernel versions using the fuse-uring implementation that contain the unpatched race, such as the pre‑pending commit 2cd9454. Affected vendors include those providing the standard Linux kernel. No specific version range is listed, so the flaw is present until the kernel is updated to include the fix.

Risk and Exploitability

The flaw does not carry a published CVSS score and its EPSS score is not available, though it is not listed in the CISA KEV catalog. The attack requires the ability to concurrently trigger a fuse ring registration and a connection abort, which is likely limited to privileged users or processes with direct access to the fuse interface. While not exploitable remotely, an attacker with sufficient local privileges could purposely use this race to cause the system to hang during unmount or shutdown, resulting in a denial‑of‑service.

Generated by OpenCVE AI on August 10, 2026 at 14:13 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Update the Linux kernel to a release that includes the commit that resolves the race condition (e.g., any kernel built after commit 2cd9454).
  • If fuse‑uring is not required for system operation, disable it or restrict its usage to reduce the attack surface.
  • Restrict the processes that can mount fuse filesystems by limiting CAP_SYS_ADMIN or using systemd user mounts, thereby reducing the chance of the race condition being triggered.

Generated by OpenCVE AI on August 10, 2026 at 14:13 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Mon, 10 Aug 2026 12:30:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: fuse-uring: fix race between registration and connection abortion This fixes this race: - thread a: io_uring_enter -> register sqe -> fuse_uring_create_ring_ent -> allocate ent but doesn't grab queue_ref yet - thread b: fuse_conn_destroy() -> fuse_chan_abort() -> fuse_uring_abort() is a no-op due to queue ref being 0 - thread a: grabs the queue_ref, queue_ref is now 1, rest of fuse_uring_do_register() logic executes - thread b: fuse_chan_abort() returns, fuse_chan_wait_aborted() now runs and calls "wait_event(ring->stop_waitq, atomic_read(&ring->queue_refs) == 0);" The abort/unmount thread will hang indefinitely in unkillable state as nothing will decrement queue_refs or wake stop_waitq, and the ring, queue, and ent are leaked. Fix this by checking fch->connected under fch->lock after the created ent has grabbed a ref count on the queue. This ensures that in the scenario above, it is guaranteed that we either release the queue ref and wake up stop_waitq (in case fuse_chan_wait_aborted() is already waiting) in fuse_uring_do_register() when we detect !fch->connected, or if the connection is aborted after the check, it is guaranteed that the async teardown worker will be running in the background cleaning up ents and decrementing the ent's ref on the queue, which will unblock the eventual queue and ring teardown.
Title fuse-uring: fix race between registration and connection abortion
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-08-10T11:58:08.590Z

Reserved: 2026-07-30T09:28:09.367Z

Link: CVE-2026-68095

cve-icon Vulnrichment

No data.

cve-icon NVD

No data.

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-08-10T14:15:03Z

Weaknesses

No weakness.