CVE-2026-80859: fuse: fix missing barrier when checking io-uring readiness
In the Linux kernel, the following vulnerability has been resolved:
fuse: fix missing barrier when checking io-uring readiness
fuseblockalloc() reads fch->initialized and then fch->iouring. fch->iouring is set before fch->initialized, ordered by the smpwmb() in fusechansetintialized(), but fuseblockalloc() has no matching read barrier between the two loads.
This may lead a CPU to observe fch->initialized=1 but fch->iouring=0, and skip the check that blocks request allocation until the io-uring queues are ready. This can reintroduce the lock-order inversion deadlock that commit 3393ff964e0f prevents.
Add an smprmb() barrier to pair with the smpwmb() in fusechansetinitialized() to prevent this.
Event History
Frequently Asked Questions
What is the practical impact if this race occurs?
A CPU can observe the FUSE channel as initialized while still seeing io-uring as unavailable, causing it to skip the allocation block intended to wait for io-uring queues. This can reintroduce a lock-order inversion deadlock.
Under what conditions can the issue be triggered?
The issue depends on concurrent observation of FUSE channel initialization and io-uring readiness, where memory-load reordering allows initialized to be seen before the earlier io_uring update. The provided data does not identify a required attacker privilege, configuration, or user-controlled trigger.
What change resolves the issue?
The fix adds an smp_rmb() read memory barrier in fuse_block_alloc() between reading the initialized and io_uring fields. This pairs with the existing smp_wmb() in fuse_chan_set_initialized() and ensures the io_uring state is observed consistently after initialization is seen.