From: "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>
To: "zdi-disclosures@trendmicro.com" <zdi-disclosures@trendmicro.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"valentina.manea.m@gmail.com" <valentina.manea.m@gmail.com>,
"shuah@kernel.org" <shuah@kernel.org>,
"i@zenithal.me" <i@zenithal.me>
Subject: Re: ZDI-CAN-22273: New Vulnerability Report
Date: Sat, 21 Oct 2023 12:10:03 +0200 [thread overview]
Message-ID: <2023102134-reflux-saddling-c750@gregkh> (raw)
In-Reply-To: <DM5PR0102MB347711AF2F5655852AC60BEB80DBA@DM5PR0102MB3477.prod.exchangelabs.com>
On Fri, Oct 20, 2023 at 03:25:27PM +0000, zdi-disclosures@trendmicro.com wrote:
> ### Analysis
>
> ```
> race condition bug exists in the usb/ip VHCI driver
> it leads to UAF on `struct usb_device`
> thread 1 thread 2
> vhci_device_reset() vhci_urb_enqueue()
> usb_put_dev(vdev->udev);
> usb_put_dev(vdev->udev); // free
> vdev->udev = usb_get_dev(urb->dev); // UAF
> vdev->udev = NULL;
> ```
>
> here is the patch in order to trigger the bug more easier
> ```
> diff --git a/drivers/usb/usbip/vhci_hcd.c b/drivers/usb/usbip/vhci_hcd.c
> index 37d1fc34e..7242244d7 100644
> --- a/drivers/usb/usbip/vhci_hcd.c
> +++ b/drivers/usb/usbip/vhci_hcd.c
> @@ -11,7 +11,7 @@
> #include <linux/module.h>
> #include <linux/platform_device.h>
> #include <linux/slab.h>
> -
> +#include <linux/delay.h>
> #include "usbip_common.h"
> #include "vhci.h"
>
> @@ -781,6 +781,7 @@ static int vhci_urb_enqueue(struct usb_hcd *hcd, struct urb *urb, gfp_t mem_flag
> usbip_dbg_vhci_hc(
> "Not yet?:Get_Descriptor to device 0 (get max pipe size)\n");
>
> + mdelay(200);
> usb_put_dev(vdev->udev);
> vdev->udev = usb_get_dev(urb->dev);
> goto out;
> @@ -1075,6 +1076,7 @@ static void vhci_device_reset(struct usbip_device *ud)
> vdev->devid = 0;
>
> usb_put_dev(vdev->udev);
> + mdelay(200);
> vdev->udev = NULL;
>
> if (ud->tcp_socket) {
> ```
So you are resetting a device while it is enumerating? That's a very
narrow window to handle, and you need a malicious device to do this,
right?
Can you submit a patch to just save off the reference of the device
before the put is called on it to be sure that all is in sync properly?
thanks,
greg k-h
next prev parent reply other threads:[~2023-10-21 10:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-20 15:25 ZDI-CAN-22273: New Vulnerability Report zdi-disclosures
2023-10-21 10:10 ` gregkh [this message]
2024-02-16 17:27 ` zdi-disclosures
2024-02-16 17:37 ` gregkh
2024-02-16 17:58 ` zdi-disclosures
2024-02-19 12:24 ` Oliver Neukum
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=2023102134-reflux-saddling-c750@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=i@zenithal.me \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=shuah@kernel.org \
--cc=valentina.manea.m@gmail.com \
--cc=zdi-disclosures@trendmicro.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