CVE-2026-68095

In the Linux kernel, the following vulnerability has been resolved:

fuse-uring: fix race between registration and connection abortion

This fixes this race: - thread a: iouringenter -> register sqe -> fuseuringcreateringent -> allocate ent but doesn't grab queueref yet - thread b: fuseconndestroy() -> fusechanabort() -> fuseuringabort() is a no-op due to queue ref being 0 - thread a: grabs the queueref, queueref is now 1, rest of fuseuringdoregister() logic executes - thread b: fusechanabort() returns, fusechanwaitaborted() now runs and calls "waitevent(ring->stopwaitq, atomicread(&ring->queuerefs) == 0);" The abort/unmount thread will hang indefinitely in unkillable state as nothing will decrement queuerefs or wake stop_waitq, and the ring, queue, and ent are leaked.

Fix this by checking fch->connected under fch->lock after the created ent has grabbed a ref count on the queue. This ensures that in the scenario above, it is guaranteed that we either release the queue ref and wake up stopwaitq (in case fusechanwaitaborted() is already waiting) in fuseuringdo_register() when we detect !fch->connected, or if the connection is aborted after the check, it is guaranteed that the async teardown worker will be running in the background cleaning up ents and decrementing the ent's ref on the queue, which will unblock the eventual queue and ring teardown.