CVE-2026-80946: fuse: copy request headers via a stack buffer for io-uring
In the Linux kernel, the following vulnerability has been resolved:
fuse: copy request headers via a stack buffer for io-uring
The fuse-io-uring transport copies req->in.h out to the ring in fuseuringcopytoring() and req->out.h back in fuseuringcommit(). Both headers live inside the fuserequest slab object, whose cache (fusereqcachep) is created without a usercopy whitelist, so copying them directly to/from userspace trips CONFIGHARDENEDUSERCOPY and panics:
usercopy: Kernel memory exposure attempt detected from SLUB object 'fuserequest' (offset 56, size 40)! kernel BUG at mm/usercopy.c:102! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:usercopyabort (mm/usercopy.c:90) Call Trace: checkheapobject (mm/slub.c:8268) checkobjectsize (mm/usercopy.c:197 mm/usercopy.c:258 mm/usercopy.c:223) copyheadertoring (fs/fuse/devuring.c:618) fuseuringpreparesend (fs/fuse/devuring.c:776 fs/fuse/devuring.c:785) fuseuringsendintask (fs/fuse/devuring.c:1306) tctxtaskworkrun (iouring/tw.c:96) taskworkrun (kernel/taskwork.c:233) ioruntaskwork (iouring/tw.h:84) iocqringwait (iouring/wait.c:278) dosysiouringenter (iouring/iouring.c:2685) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:121)
Bounce both headers through an on-stack copy so the usercopy touches stack memory, not the slab object.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to the observed failure?
The failure is relevant to Linux systems using the FUSE io-uring transport with CONFIG_HARDENED_USERCOPY enabled. The reported panic occurs when request headers in a fuse_request SLUB object are copied directly between kernel memory and the ring.
How can I tell whether this issue has occurred?
Kernel logs may report a Hardened Usercopy violation for the 'fuse_request' SLUB object, including “Kernel memory exposure attempt detected” with an offset of 56 and size of 40. The report can culminate in a kernel BUG in mm/usercopy.c and an invalid-opcode Oops, with calls involving copy_header_to_ring or fuse_uring_prepare_send.
What remediation is indicated by the available information?
Use a Linux kernel update that includes the resolved change referenced by the listed stable-kernel commits. The fix copies the request headers through a stack buffer rather than directly from or into the fuse_request slab object.