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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.