From: Shuah Khan <skhan@linuxfoundation.org>
To: Michael Bommarito <michael.bommarito@gmail.com>,
Valentina Manea <valentina.manea.m@gmail.com>,
Shuah Khan <shuah@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-usb@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, Zheng Wang <zyytlz.wz@163.com>,
Zheng Hacker <hackerzheng666@gmail.com>,
Shuah Khan <skhan@linuxfoundation.org>
Subject: Re: [PATCH] usbip: vudc: Fix use after free bug in vudc_remove due to race condition
Date: Tue, 5 May 2026 12:02:13 -0600 [thread overview]
Message-ID: <052eafb8-03f9-48a7-a1b4-4c366f120d51@linuxfoundation.org> (raw)
In-Reply-To: <20260417163552.807548-1-michael.bommarito@gmail.com>
On 4/17/26 10:35, Michael Bommarito wrote:
> This patch follows up Zheng Wang's 2023 report of a use-after-free in
> vudc_remove(). The original thread stalled on Shuah Khan's request for
> runtime testing of the unplug/unbind path. This patch supplies that
> testing and keeps Zheng's original fix shape.
>
> In vudc_probe(), v_init_timer() binds udc->tr_timer.timer to v_timer().
> usbip_sockfd_store() starts the timer via v_start_timer()/v_kick_timer().
> vudc_remove() can then free the containing struct vudc while the timer is
> still pending or executing.
>
> KASAN confirms the race on an unpatched x86_64 QEMU guest with
> CONFIG_KASAN=y, CONFIG_USBIP_VUDC=y, CONFIG_USB_ZERO=y, and a tight loop
> that repeatedly writes a socket fd to usbip_sockfd, closes the socket
> pair, and unbinds/rebinds usbip-vudc.0:
>
> BUG: KASAN: slab-use-after-free in __run_timer_base.part.0+0x8ba/0x8e0
> Write of size 8 at addr ffff888001b80740 by task trigger_and_unb/239
> Allocated by task 239:
> vudc_probe+0x4d/0xaa0
> Freed by task 239:
> kfree+0x18f/0x520
> device_release_driver_internal+0x388/0x540
> unbind_store+0xd9/0x100
>
> This lands in the timer core rather than v_timer() itself because the
> embedded timer_list is being walked after its containing struct vudc has
> already been freed. The underlying lifetime bug is the same one Zheng
> reported.
>
> With v_stop_timer() called from vudc_remove() and the timer deleted
> synchronously, the same harness completed 5000 bind/unbind iterations
> with no KASAN report.
>
> Fixes: b6a0ca111867 ("usbip: vudc: Add UDC specific ops")
> Reported-by: Zheng Wang <zyytlz.wz@163.com>
> Closes: https://lore.kernel.org/linux-usb/20230317100954.2626573-1-zyytlz.wz@163.com/
> Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
> ---
> drivers/usb/usbip/vudc_dev.c | 1 +
> drivers/usb/usbip/vudc_transfer.c | 3 ++-
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/usbip/vudc_dev.c b/drivers/usb/usbip/vudc_dev.c
> index 90383107b660..c5f079c5a1ea 100644
> --- a/drivers/usb/usbip/vudc_dev.c
> +++ b/drivers/usb/usbip/vudc_dev.c
> @@ -632,6 +632,7 @@ void vudc_remove(struct platform_device *pdev)
> {
> struct vudc *udc = platform_get_drvdata(pdev);
>
> + v_stop_timer(udc);
> usb_del_gadget_udc(&udc->gadget);
> cleanup_vudc_hw(udc);
> kfree(udc);
> diff --git a/drivers/usb/usbip/vudc_transfer.c b/drivers/usb/usbip/vudc_transfer.c
> index a4f02ea3e3ef..d4ce85c4c6a2 100644
> --- a/drivers/usb/usbip/vudc_transfer.c
> +++ b/drivers/usb/usbip/vudc_transfer.c
> @@ -490,7 +490,8 @@ void v_stop_timer(struct vudc *udc)
> {
> struct transfer_timer *t = &udc->tr_timer;
>
> - /* timer itself will take care of stopping */
> + /* Delete the timer synchronously before teardown frees udc. */
> dev_dbg(&udc->pdev->dev, "timer stop");
> + timer_delete_sync(&t->timer);
> t->state = VUDC_TR_STOPPED;
> }
Looks good to me.
Acked-by: Shuah Khan <skhan@linuxfoundation.org>
thanks,
-- Shuah
prev parent reply other threads:[~2026-05-05 18:02 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-17 10:09 [PATCH v3] usbip: vudc: Fix use after free bug in vudc_remove due to race condition Zheng Wang
2023-03-17 22:53 ` Shuah Khan
2023-03-18 7:39 ` Zheng Hacker
2023-04-13 8:09 ` Zheng Hacker
2023-04-13 18:01 ` Shuah Khan
2023-04-14 2:33 ` Zheng Hacker
2026-04-17 16:35 ` [PATCH] " Michael Bommarito
2026-05-05 18:02 ` Shuah Khan [this message]
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=052eafb8-03f9-48a7-a1b4-4c366f120d51@linuxfoundation.org \
--to=skhan@linuxfoundation.org \
--cc=gregkh@linuxfoundation.org \
--cc=hackerzheng666@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=michael.bommarito@gmail.com \
--cc=shuah@kernel.org \
--cc=valentina.manea.m@gmail.com \
--cc=zyytlz.wz@163.com \
/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