[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DM5PR0102MB3477B594C9D018BC884DF3E4804C2@DM5PR0102MB3477.prod.exchangelabs.com>
Date: Fri, 16 Feb 2024 17:27:57 +0000
From: "zdi-disclosures@...ndmicro.com" <zdi-disclosures@...ndmicro.com>
To: "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
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
Hello,
Do you have any updates to share regarding this vulnerability? The 120-day deadline for this case was January 31, 2024. We will publish this soon in accordance with the ZDI 120-day Disclosure policy if there is not an available fix.
Regards,
The ZDI Team
-----Original Message-----
From: gregkh@...uxfoundation.org <gregkh@...uxfoundation.org>
Sent: Saturday, October 21, 2023 6:10 AM
To: ZDI Disclosures Mailbox <zdi-disclosures@...ndmicro.com>
Cc: linux-kernel@...r.kernel.org; linux-usb@...r.kernel.org; valentina.manea.m@...il.com; shuah@...nel.org; 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
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
For details about what personal information we collect and why, please see our Privacy Notice on our website at: Read privacy policy<http://www.trendmicro.com/privacy>
Powered by blists - more mailing lists