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 didnt get enabled because of missing FUSE_INIT reply flag FUSE_OVER_IO_URING. Without the reply flag the barrier in fuse_uring_ready() doesnt 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.

Affected Software

References

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