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
next prev parent 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®