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

Summary

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.

Timeline

1. Sep 17, 2026, 4:06 PM UTCCVE published
2. Oct 19, 2026, 8:57 AM UTCRecord last updated

Affected versions

• Linux Linux

  From 3393ff964e0fa5def66570c54a4612bf9df06b76 · fixed in 1ca1df82d9248fc0b5ff17d45607484f18e5d60b; From 3393ff964e0fa5def66570c54a4612bf9df06b76 · fixed in 8f9a725d89711ad027f6b7183586ef91528f106d; From 3393ff964e0fa5def66570c54a4612bf9df06b76 · fixed in 1f59015e958174e89be58cc8db16d70a60d17255

• Linux Linux

  6.14

• KernelLinux

  From 6.14.0 · fixed in 6.18.57; From 6.19.0 · fixed in 7.2.6

References 3