CVE-2026-68095

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fuse-uring: fix race between registration and connection abortion<br /> <br /> This fixes this race:<br /> - thread a: io_uring_enter -&gt; register sqe -&gt;<br /> fuse_uring_create_ring_ent -&gt; allocate ent but doesn&amp;#39;t grab queue_ref<br /> yet<br /> - thread b: fuse_conn_destroy() -&gt; fuse_chan_abort() -&gt;<br /> fuse_uring_abort() is a no-op due to queue ref being 0<br /> - thread a: grabs the queue_ref, queue_ref is now 1, rest of<br /> fuse_uring_do_register() logic executes<br /> - thread b: fuse_chan_abort() returns, fuse_chan_wait_aborted() now runs<br /> and calls<br /> "wait_event(ring-&gt;stop_waitq, atomic_read(&amp;ring-&gt;queue_refs) == 0);"<br /> The abort/unmount thread will hang indefinitely in unkillable state as<br /> nothing will decrement queue_refs or wake stop_waitq, and the ring,<br /> queue, and ent are leaked.<br /> <br /> Fix this by checking fch-&gt;connected under fch-&gt;lock after the created<br /> ent has grabbed a ref count on the queue. This ensures that in the<br /> scenario above, it is guaranteed that we either release the queue ref<br /> and wake up stop_waitq (in case fuse_chan_wait_aborted() is already<br /> waiting) in fuse_uring_do_register() when we detect !fch-&gt;connected, or<br /> if the connection is aborted after the check, it is guaranteed that the<br /> async teardown worker will be running in the background cleaning up ents<br /> and decrementing the ent&amp;#39;s ref on the queue, which will unblock the<br /> eventual queue and ring teardown.