[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2023102134-reflux-saddling-c750@gregkh>
Date: Sat, 21 Oct 2023 12:10:03 +0200
From: "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
To: "zdi-disclosures@...ndmicro.com" <zdi-disclosures@...ndmicro.com>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
"valentina.manea.m@...il.com" <valentina.manea.m@...il.com>,
"shuah@...nel.org" <shuah@...nel.org>,
"i@...ithal.me" <i@...ithal.me>
Subject: Re: ZDI-CAN-22273: New Vulnerability Report
On Fri, Oct 20, 2023 at 03:25:27PM +0000, zdi-disclosures@...ndmicro.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
Powered by blists - more mailing lists