Answer in brief
CVE-2026-90095 records a Unknown severity vulnerability in fuse: Fix the condition to enable over-io-uring. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=3393ff964e0fa5def66570c54a4612bf9df06b76 <8f9a725d89711ad027f6b7183586ef91528f106d || >=3393ff964e0fa5def66570c54a4612bf9df06b76 <1f59015e958174e89be58cc8db16d70a60d17255 | 8f9a725d89711ad027f6b7183586ef91528f106d, 1f59015e958174e89be58cc8db16d70a60d17255 |
| Linux/Linuxgeneric | 6.14 | Not reported |
| Linux/Linuxgeneric | >=3393ff964e0fa5def66570c54a4612bf9df06b76 <1ca1df82d9248fc0b5ff17d45607484f18e5d60b || >=3393ff964e0fa5def66570c54a4612bf9df06b76 <8f9a725d89711ad027f6b7183586ef91528f106d || >=3393ff964e0fa5def66570c54a4612bf9df06b76 <1f59015e958174e89be58cc8db16d70a60d17255 | 1ca1df82d9248fc0b5ff17d45607484f18e5d60b, 8f9a725d89711ad027f6b7183586ef91528f106d, 1f59015e958174e89be58cc8db16d70a60d17255 |
Published upstream
Sep 17, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Oct 19, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Sep 17, 2026
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.
Quoted source text, attributed separately from HOL analysis.