Re: [PATCH 1/2] fuse: copy request headers via a stack buffer for io-uring
Xiang Mei <[email protected]> Tue, 7 Jul 2026 11:29:59 -0700
| Newsgroups | dev.linux.lists.fuse-devel,org.kernel.vger.linux-kernel,org.kernel.vger.stable |
|---|---|
| Message-ID | <CAPpSM+T4D+Ym=JwA-zqx5RvRzktN2--WJnOrt=3xcuTRoyW09A@mail.gmail.com> |
On Mon, Jul 6, 2026 at 10:40 PM Darrick J. Wong <[email protected]> wrote: > > On Mon, Jul 06, 2026 at 02:17:12PM -0700, Joanne Koong wrote: > > On Mon, Jul 6, 2026 at 12:13 PM Xiang Mei <[email protected]> wrote: > > > > > > The fuse-io-uring transport copies req->in.h out to the ring in > > > fuse_uring_copy_to_ring() and req->out.h back in fuse_uring_commit(). > > > Both headers live inside the fuse_request slab object, whose cache > > > (fuse_req_cachep) is created without a usercopy whitelist, so copying > > > them directly to/from userspace trips CONFIG_HARDENED_USERCOPY and > > > panics: > > > > > > usercopy: Kernel memory exposure attempt detected from SLUB object > > > 'fuse_request' (offset 56, size 40)! > > > kernel BUG at mm/usercopy.c:102! > > > RIP: 0010:usercopy_abort+0x6c/0x80 > > > Call Trace: > > > __check_heap_object > > > __check_object_size > > > copy_header_to_ring fs/fuse/dev_uring.c:618 > > > fuse_uring_prepare_send > > > fuse_uring_send_in_task > > > ... > > > __do_sys_io_uring_enter > > > entry_SYSCALL_64_after_hwframe > > > > > > Bounce both headers through an on-stack copy so the usercopy touches > > > stack memory, not the slab object. > > > > > > Fixes: c090c8abae4b ("fuse: Add io-uring sqe commit and fetch support") > > > Reported-by: Weiming Shi <[email protected]> > > > Assisted-by: Claude:claude-opus-4-8 > > > Signed-off-by: Xiang Mei <[email protected]> > > > > Reviewed-by: Joanne Koong <[email protected]> > > > > I think the cc [email protected] tag is missing here. I added > > stable@ to the cc list on this email, but I'm not sure if they require > > the tag being explicitly in the commit message to get it backported. > > I used to like it for XFS once upon a time when we did manual reviews > and QA of LTS branches, because it was a headsup for something that I > should actually watch to make sure it actually showed up in stable-rc. > > --D Hi Joanne, Darrick, Thanks for the review! From what I've observed, the "Fixes:" tag alone is often enough to get a patch backported, though I'm not certain that's guaranteed. Adding the explicit "Cc: [email protected]" tag makes it reliable either way; feel free to let me know if we need a v2. Xiang