GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel FUSE: io_uring queues published without release ordering can be read half-initialized

UnscoredCVE-2026-80858Kernel, userspace & hypervisorcurated

Impact

fuse_uring_create_queue() initializes a fuse_ring_queue and then publishes the pointer into ring->queues[qid] with a plain WRITE_ONCE(), which orders the store but not the field initialization that precedes it. Several readers fetch that pointer locklessly and dereference it, so on a weakly ordered CPU a reader can observe the published pointer while the queue's fields are still uninitialized; the plain accesses on those read paths are undefined behaviour regardless. The practical outcome is a kernel crash or memory corruption on a node running a FUSE server that uses the io_uring transport, taking every workload on that node down with it. This is a race in the setup path rather than a directed exploit primitive, and the record describes no privilege-escalation path.

Who can reach it

Local, and only on nodes where a FUSE daemon negotiates the io_uring transport. Reaching the race requires queue creation to run concurrently with the lockless readers; the record does not describe attacker-controlled timing, and there is no remote or cross-node path.

What to do

Update to a stable kernel carrying the fix (publish with smp_store_release(), read with READ_ONCE()) and reboot the node. The exposure is confined to FUSE servers that enable io_uring, so operators who do not run one can defer to their normal kernel cadence rather than opening a window. Only the kernel commits are referenced.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.