CVE-2026-90095

What the bug is

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.

Where it lives

The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.

fs/fuse/dev_uring.c
fs/fuse/inode.c

What this is

FUSE FILESYSTEM [IO-URING]MAINTAINERS section matched on fs/fuse/dev_uring.c · fuse-devel@lists.linux.dev · Maintained

Kernel module

fuse

Check it on the machine

grep -wE 'CONFIG_FUSE_FS|CONFIG_FUSE_IO_URING' /boot/config-$(uname -r)

Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.

lsmod | grep -w fuse

Prints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.

Show whether Debian builds this, per release

Debian builds this code. Every release below compiles the affected file into the kernels it ships.

• bookwormm
• trixie, forky, sidy

m

a loadable module on every flavour - check lsmod, can be blacklisted

y

built into the kernel image on every flavour - only a patch removes it

Build switches

CONFIG_FUSE_FS, CONFIG_FUSE_IO_URING

Reads as

all on means the file is compiled; any one off means it is not.

From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages

Signals

Published

2026-09-17 (31 days ago)source

CVSS

no vector published, unrated

Attack vector

not published

EPSS

0.21%, higher than 10.0% of all CVEssource

CISA KEV

not listedthe KEV catalogue

Debian urgency

unimportantsource

Subsystem

fs/fuse

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

Introduced	Fixed in	Commit
6.14	6.18.57	1ca1df82d924
6.14	7.2.6	8f9a725d8971
6.14	7.3	1f59015e9581