CVE intelligence

CVE-2026-90095

Vulnerability intelligence

Published Sep 17, 2026Sources checked Oct 21, 2026

N/ACVSS not listedScore unavailable

What this means

Review the available evidence

CVE-2026-90095. It is not in the current CISA KEV record we collected. That does not prove exploitation has not occurred.

CISA KEVNot listedBased on the latest collected catalog

EPSS0.2%Estimated 30-day exploitation probability

Ransomware useNot markedCISA KEV ransomware field

Threat actors0Source-linked actor relationships

Overview

What is CVE-2026-90095?

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.

Source: NVD