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

fuse: Fix the condition to enable over-io-uring

The existing condition in fuse_uring_cmd() is there only to avoid
disabling io-uring for connections that already run with it, missing
was a condition to refuse any IORING_OP_URING_CMD if the
connection/channel didn't get enabled because of missing FUSE_INIT
reply flag FUSE_OVER_IO_URING. Without the reply flag the barrier in
fuse_uring_ready() doesn't work and IO could already be going on and
cause deadlock states (at a minimum one between fch->bg_lock and
queue->lock).

The change itself is trivial, but brings behavior change,
FUSE_OVER_IO_URING has to be set in the FUSE_INIT_REPLY by fuse servers
to accept any IORING_OP_URING_CMD. Libfuse does that and the only
non-libfuse implementation I found (fractal-fuse) also does it.
Qemu patches for fuse-io-uring are not merged yet, as far as I know.

Moved up is the smp_load_acquire(&fch->initialized) check, as a
fuse-server implementation might try to setup io-uring before FUSE_INIT
is processed and might have gotten -EOPNOTSUPP instead of -EAGAIN.

Also fixed is a stale comment that explains the handling of the
FUSE_OVER_IO_URING flag in early RFC versions.

If there should be a report from any library or application we
probably need to revert this commit.
Published: 2026-09-17
Score: n/a
EPSS: < 1% Very Low
KEV: No
Impact: Denial of Service
Action: Apply Patch
AI Analysis

Impact

The Linux kernel’s fuse module contains a race condition where the function reading the FUSE_INIT_REPLY fails to verify the presence of the FUSE_OVER_IO_URING flag before accepting any IORING_OP_URING_CMD. This missing check allows the fuse_uring_ready() barrier to be bypassed, thereby letting I/O operations proceed and potentially deadlock the fuse channel background lock with the queue lock. As a result the affected FUSE server can hang services that depend on fuse io-uring, creating a denial‑of‑service scenario.

Affected Systems

All Linux kernel builds that compile with the fuse module and have not incorporated the patch that restores the proper flag check are potentially vulnerable. The issue applies generically to the Linux kernel rather than to a specific distribution; any distribution shipping a kernel version without this fix is impacted. The specific vendor name is Linux:Linux.

Risk and Exploitability

The EPSS score is reported as < 1%, indicating a very low percentage of anticipated live exploitation. The vulnerability is not listed in the CISA KEV catalog. Attackers would likely need local or elevated privileges to send the malformed fuse commands that trigger the deadlock, so the attack vector is inferred to be local. Given the lack of remote triggers, the overall risk is moderate, but systems that enable fuse io-uring should apply the fix promptly to avoid availability loss.

Generated by OpenCVE AI on September 20, 2026 at 04:24 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Update the Linux kernel to a version that includes the commit fixing the fuse_uring_cmd() condition
  • Disable fuse in the kernel configuration or prevent its loading if the system does not require it
  • If an update is unavailable, temporarily disable io-uring support for fuse via a module parameter or config change

Generated by OpenCVE AI on September 20, 2026 at 04:24 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Sun, 20 Sep 2026 04:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-665

Thu, 17 Sep 2026 16:30:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: fuse: Fix the condition to enable over-io-uring The existing condition in fuse_uring_cmd() is there only to avoid disabling io-uring for connections that already run with it, missing was a condition to refuse any IORING_OP_URING_CMD if the connection/channel didn't get enabled because of missing FUSE_INIT reply flag FUSE_OVER_IO_URING. Without the reply flag the barrier in fuse_uring_ready() doesn't work and IO could already be going on and cause deadlock states (at a minimum one between fch->bg_lock and queue->lock). The change itself is trivial, but brings behavior change, FUSE_OVER_IO_URING has to be set in the FUSE_INIT_REPLY by fuse servers to accept any IORING_OP_URING_CMD. Libfuse does that and the only non-libfuse implementation I found (fractal-fuse) also does it. Qemu patches for fuse-io-uring are not merged yet, as far as I know. Moved up is the smp_load_acquire(&fch->initialized) check, as a fuse-server implementation might try to setup io-uring before FUSE_INIT is processed and might have gotten -EOPNOTSUPP instead of -EAGAIN. Also fixed is a stale comment that explains the handling of the FUSE_OVER_IO_URING flag in early RFC versions. If there should be a report from any library or application we probably need to revert this commit.
Title fuse: Fix the condition to enable over-io-uring
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-09-17T16:06:08.197Z

Reserved: 2026-09-11T19:38:34.786Z

Link: CVE-2026-90095

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-17T17:17:01.123

Modified: 2026-09-17T17:17:01.123

Link: CVE-2026-90095

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-20T04:30:18Z

Weaknesses