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.
Metrics
No CVSS score has been published yet.
Affected software
Source: the vendor's advisory (CNA). NVD analysis pending.
| Vendor | Product | Versions |
|---|---|---|
| Linux | Linux | >= 3393ff964e0fa5def66570c54a4612bf9df06b76, < 1ca1df82d9248fc0b5ff17d45607484f18e5d60b; >= 3393ff964e0fa5def66570c54a4612bf9df06b76, < 8f9a725d89711ad027f6b7183586ef91528f106d; >= 3393ff964e0fa5def66570c54a4612bf9df06b76, < 1f59015e958174e89be58cc8db16d70a60d17255 |
| Linux | Linux | 6.14 |
References
Timeline
- Published
- Sep 17, 2026
- Last modified
- Oct 19, 2026
- NVD status
- Received