Description (CNA)
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.
Affected (CNA)
| Vendor / product | Versions |
|---|---|
| Linux / Linux | affected 3393ff964e0fa5def66570c54a4612bf9df06b76 before 1ca1df82d9248fc0b5ff17d45607484f18e5d60b; affected 3393ff964e0fa5def66570c54a4612bf9df06b76 before 8f9a725d89711ad027f6b7183586ef91528f106d; affected 3393ff964e0fa5def66570c54a4612bf9df06b76 before 1f59015e958174e89be58cc8db16d70a60d17255 |
| Linux / Linux | affected 6.14; unaffected 0 before 6.14; unaffected 6.18.57 through 6.18.*; unaffected 7.2.6 through 7.2.*; unaffected 7.3 through * |
CWE
No CWE identifiers supplied.