Re: [PATCH usb-next v2] USB: gadgetfs: Fix use-after-free in gadgetfs_kill_sb
From: Alan Stern
Date: Tue Sep 01 2026 - 21:50:37 EST
On Tue, Sep 01, 2026 at 04:12:17PM -0700, Rafael Alejandro Díaz Cruz wrote:
> I kept going at it and finally realized what was going on.
>
> I added some logging statements as you suggested and
> found that my 'how this bug is caused' is correct. It does
> come from calling get_dev() after the error
> paths, and the simple solution was to move get_dev()
> right after the set_gadget_data().
>
> As for 'why' the bug is happening, it basically comes from
> the reproducer using failslab to force kmalloc() to fail inside
> of usb_ep_alloc_request(). This will cause the following
> error path to be taken:
>
> dev->req = usb_ep_alloc_request (gadget->ep0, GFP_KERNEL);
> if (!dev->req) // This is true on failslab
> goto enomem;
>
> This will then skip get_dev() and go directly to
> gadgetfs_unbind() -> put_dev()
> creating the unbalanced refcount.
Well, yes, it was pretty clear that either the usb_ep_alloc_request()
call or the activate_ep_files() call had to be failing, given that the
unbalanced refcount came from gadgetfs_bind()'s error path. The only
questions were which one, and how. With the reproducer introducing
random memory allocation failures, either one of those calls could go
wrong.
> It was tricky to understand given that it was failing only
> on the N-th failslab attempt. Luckily gdb could do all the
> things I needed.
>
> I'm also happy to share that even Claude was not able to
> figure this out and could only confirm this was the cause
> after I pointed it out.
>
> I'm certain of what I found and will proceed to create the
> next patch with an updated message.
>
> Please let me know if there is anything else I should add.
> I'll wait for your response before sending it out.
No, this seems good. Make sure that your patch description is both
precise and concise, and that it doesn't presume the reader is already
familiar with the details of your testing.
In fact, since you're fixing two distinct (albeit similar) bugs, you
might want to split this up into two separate patches.
Alan Stern