linux-kernel - Re: [BUG] KASAN: slab-use-after-free Read in xhci_hub

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <a78536aa-ca01-47e7-a1c5-6ac3113b0dd5@rowland.harvard.edu>
Date: Fri, 18 Jul 2025 09:30:47 -0400
From: Alan Stern <stern@...land.harvard.edu>
To: cen zhang <zzzccc427@...il.com>
Cc: mathias.nyman@...el.com, gregkh@...uxfoundation.org,
	linux-kernel@...r.kernel.org, baijiaju1990@...il.com,
	zhenghaoran154@...il.com, r33s3n6@...il.com,
	linux-usb@...r.kernel.org, gality365@...il.com
Subject: Re: [BUG] KASAN: slab-use-after-free Read in xhci_hub_control

On Fri, Jul 18, 2025 at 10:40:47AM +0800, cen zhang wrote:
> Hi Greg,
> 
> Thank you for your guidance.
> 
> I've collected more specific information about the test environment
> and the reproducer's behavior, which I believe provides a clearer
> picture of the issue.
> 
> The C reproducer is hardcoded to target /dev/bus/usb/002/001, which
> corresponds to the XHCI root hub on the USB 3.0 (5000M) bus.
> 
> Below is the cleaned-up version of the C reproducer used to trigger the issue:
> 
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> #include <fcntl.h>
> #include <unistd.h>
> #include <dirent.h>
> #include <errno.h>
> #include <sys/ioctl.h>
> #include <linux/usbdevice_fs.h>
> #include <linux/usb/ch9.h>
> 
> 
> int main(void)
> {
>     int fd = open("/dev/bus/usb/002/001", O_RDWR);
>     if (fd < 0) {
>         fprintf(stderr, "Could not find or open any USB hub device.
> Aborting.\n");
>         return EXIT_FAILURE;
>     }
>     printf("Successfully opened a hub device (fd=%d).\n", fd);
> 
>     struct usb_ctrlrequest ctrl;
>     struct usbdevfs_urb urb;
> 
>     memset(&ctrl, 0, sizeof(ctrl));
>     memset(&urb, 0, sizeof(urb));
> 
>     ctrl.bRequestType = USB_DIR_IN | USB_TYPE_CLASS | USB_RECIP_OTHER; // 0xa3
>     ctrl.bRequest = 0;
>     ctrl.wValue = 0;
>     ctrl.wIndex = 0x8001; // This unusual value is preserved as it is
> likely key to the bug
>     ctrl.wLength = 0;
> 
>     urb.type = USBDEVFS_URB_TYPE_CONTROL; // Value is 2
>     urb.endpoint = 0; // Control requests are always on endpoint 0
>     urb.buffer = &ctrl; // Point the URB's data buffer to our control request
>     urb.buffer_length = sizeof(ctrl); // The size of the control request data
> 
>     printf("Submitting control URB to the hub...\n");
> 
>     // Submit the URB via ioctl. The magic number 0x8038550a is
> USBDEVFS_SUBMITURB.
>     int ret = ioctl(fd, USBDEVFS_SUBMITURB, &urb);
>     if (ret < 0) {
>         perror("ioctl(USBDEVFS_SUBMITURB) failed");
>     } else {
>         printf("ioctl call succeeded.\n");
>     }
> 
>     close(fd);
>     return 0;
> }

That helps a lot.  It shows that there is indeed a bug in the xhci-hcd 
driver.  And yes, the peculiar wIndex value is the key.  The patch below 
ought to fix the bug.

Alan Stern


Index: usb-devel/drivers/usb/host/xhci-hub.c
===================================================================
--- usb-devel.orig/drivers/usb/host/xhci-hub.c
+++ usb-devel/drivers/usb/host/xhci-hub.c
@@ -1259,7 +1259,7 @@ int xhci_hub_control(struct usb_hcd *hcd
 		spin_unlock_irqrestore(&xhci->lock, flags);
 		return retval;
 	case GetPortStatus:
-		if (!portnum1 || portnum1 > max_ports)
+		if (!wIndex || wIndex > max_ports)
 			goto error;
 
 		wIndex--;