GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel FUSE: missing read barrier in the io-uring readiness check can reintroduce a lock-order deadlock

UnscoredCVE-2026-80859Kernel, userspace & hypervisorcurated

Impact

fuse_block_alloc() reads fch->initialized and then fch->io_uring with no read barrier between the two loads, while the writer orders them with an smp_wmb(). A CPU can therefore observe initialized=1 alongside io_uring=0, skip the check that blocks request allocation until the io-uring queues are ready, and reintroduce the lock-order inversion deadlock that commit 3393ff964e0f was written to prevent. The exposure is availability, not memory safety: the record describes no corruption and no privilege gain. On a fleet node it surfaces as hung tasks in whatever FUSE filesystem is mounted - fuse-overlayfs for rootless containers, object-store gateways, model and dataset caches - and a wedged FUSE mount generally cannot be cleared without killing the workloads sitting on it. It needs the reordering window, so weakly-ordered hosts such as arm64 GPU nodes are the realistic case.

Who can reach it

Local: any user or container able to drive a FUSE filesystem that uses fuse-over-io-uring during the window in which the connection is coming up. No authentication beyond ordinary access to the node, and no exposure at all on hosts with no fuse-over-io-uring mount.

What to do

Update to a stable kernel containing commit dd9c8357 or edb310bc and reboot each node; the fix is a one-line smp_rmb() in FUSE core and ships as a kernel update, not a daemon restart. No fixed release number is given in the record. FUSE mounts that do not use the io-uring path are unaffected in the meantime.

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.