CVE-2026-90095: fuse: Fix the condition to enable over-io-uring
In the Linux kernel, the following vulnerability has been resolved:
fuse: Fix the condition to enable over-io-uring
The existing condition in fuseuringcmd() is there only to avoid disabling io-uring for connections that already run with it, missing was a condition to refuse any IORINGOPURINGCMD if the connection/channel didn't get enabled because of missing FUSEINIT reply flag FUSEOVERIOURING. Without the reply flag the barrier in fuseuringready() doesn't work and IO could already be going on and cause deadlock states (at a minimum one between fch->bglock and queue->lock).
The change itself is trivial, but brings behavior change, FUSEOVERIOURING has to be set in the FUSEINITREPLY by fuse servers to accept any IORINGOPURINGCMD. 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 smploadacquire(&fch->initialized) check, as a fuse-server implementation might try to setup io-uring before FUSEINIT is processed and might have gotten -EOPNOTSUPP instead of -EAGAIN.
Also fixed is a stale comment that explains the handling of the FUSEOVERIOURING flag in early RFC versions.
If there should be a report from any library or application we probably need to revert this commit.
Event History
Frequently Asked Questions
Which FUSE deployments are exposed to the deadlock condition?
The issue applies when a FUSE connection or channel accepts IORING_OP_URING_CMD without having enabled FUSE-over-io-uring through the FUSE_OVER_IO_URING flag in its FUSE_INIT reply. In that state, I/O may already be active while the expected barrier is ineffective, allowing deadlock states involving fch->bg_lock and queue->lock.
What must be true for IORING_OP_URING_CMD to be accepted safely?
The FUSE server must set FUSE_OVER_IO_URING in the FUSE_INIT reply. The corrected behavior refuses IORING_OP_URING_CMD when that flag was not negotiated.
How can an operator determine whether a FUSE server configuration is affected?
Inspect the server's FUSE_INIT reply and determine whether it includes FUSE_OVER_IO_URING. A server that does not advertise that flag should not accept IORING_OP_URING_CMD; acceptance in that situation indicates the vulnerable behavior.
What can be done if the kernel fix cannot be deployed immediately?
Avoid using IORING_OP_URING_CMD on FUSE connections that have not negotiated FUSE_OVER_IO_URING. FUSE server implementations should advertise FUSE_OVER_IO_URING in their FUSE_INIT reply only when they support FUSE-over-io-uring.