mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Hui Peng <benquike@gmail.com>
Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] usb: gadget: f_hid: fix use-after-free of hidg->func.config after unbind
Date: Sat, 19 Sep 2026 11:28:51 +0100	[thread overview]
Message-ID: <2026091930-corporate-destiny-7b45@gregkh> (raw)
In-Reply-To: <20260919090724.3256109-2-benquike@gmail.com>

On Sat, Sep 19, 2026 at 09:07:24AM +0000, Hui Peng wrote:
> The /dev/hidgN character device stays open across function unbind: a
> process can open it, then remove the configfs gadget (echo "" > UDC,
> unlink the function from the config, rmdir the config directory), and
> keep using the still open file descriptor.
> 
> hidg_unbind() does not clear hidg->func.config, so the file operations
> continue to dereference the struct usb_configuration that configfs has
> already freed. f_hidg_get_report() does so unconditionally on entry:
> 
> 	struct usb_composite_dev *cdev = hidg->func.config->cdev;
> 
> which gives a use-after-free read on the first ioctl() after the config
> directory is removed:
> 
>  ==================================================================
>  BUG: KASAN: slab-use-after-free in f_hidg_get_report.isra.0+0x401/0x4a0
>  Read of size 8 at addr ffff8881073d7950 by task init/172
> 
>  CPU: 2 UID: 0 PID: 172 Comm: init Not tainted 7.3.0-rc3-g5dd1818b15d9 #1 PREEMPT(lazy)
>  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
>  Call Trace:
>   <TASK>
>   dump_stack_lvl+0x70/0xa0
>   print_report+0x153/0x4c6
>   kasan_report+0xf1/0x120
>   f_hidg_get_report.isra.0+0x401/0x4a0
>   f_hidg_ioctl+0xe1/0x110
>   __x64_sys_ioctl+0x184/0x1d0
>   do_syscall_64+0xda/0x4b0
>   entry_SYSCALL_64_after_hwframe+0x77/0x7f
>   </TASK>
> 
>  Allocated by task 1:
>   __kmalloc_cache_noprof+0x16a/0x380
>   config_desc_make+0x1e6/0x590
>   configfs_mkdir+0x4e9/0xe10
>   vfs_mkdir+0x2ed/0x790
>   __x64_sys_mkdir+0x6f/0xa0
> 
>  Freed by task 1:
>   kfree+0x159/0x420
>   config_item_cleanup+0x148/0x1e0
>   config_item_put+0x90/0xb0
>   configfs_rmdir+0x816/0xa50
>   vfs_rmdir+0x2e6/0x810
>   __x64_sys_rmdir+0x4b/0x70
> 
>  The buggy address belongs to the object at 0xffff8881073d7800
>   which belongs to the cache kmalloc-1k of size 1024
>  ==================================================================
> 
> A second splat follows from the ERROR() call in the same function.
> 
> Clear hidg->func.config in hidg_unbind() and check it in the paths that
> are reachable from an open file descriptor - f_hidg_read(),
> f_hidg_write() and f_hidg_get_report() - returning -ENODEV once the
> function is gone. f_hidg_req_complete() only uses the pointer to emit an
> error message, so guard that dereference as well.
> 
> While at it, drop the report_list entries in hidg_unbind(). They are
> allocated by f_hidg_get_report() and were only ever freed when the
> whole f_hidg was released, so reports queued before an unbind leaked.
> 
> Assisted-by: LLM
> Signed-off-by: Hui Peng <benquike@gmail.com>
> ---
> No Fixes: tag: I could not identify a single commit that introduced
> the problem with confidence, so I have left it out rather than guess.

Please have your llm figure that out, worst case it's when it showed up,
right?

thanks,

greg k-h

  reply	other threads:[~2026-09-19 10:30 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-19  9:07 [PATCH 1/2] usb: gadget: f_hid: don't call copy_from_user() under get_report_spinlock Hui Peng
2026-09-19  9:07 ` [PATCH 2/2] usb: gadget: f_hid: fix use-after-free of hidg->func.config after unbind Hui Peng
2026-09-19 10:28   ` Greg Kroah-Hartman [this message]
2026-09-19 10:28 ` [PATCH 1/2] usb: gadget: f_hid: don't call copy_from_user() under get_report_spinlock Greg Kroah-Hartman
2026-09-19 11:00   ` [PATCH v2 " Hui Peng
2026-09-19 11:00     ` [PATCH v2 2/2] usb: gadget: f_hid: fix use-after-free of hidg->func.config after unbind Hui Peng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2026091930-corporate-destiny-7b45@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=benquike@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®