RE: [PATCH 5.15 103/779] USB: gadget: Fix use-after-free Read in usb_udc_uevent()

[<nobuhiro1.iwamatsu@xxxxxxxxxxxxx>]

Hi,

This patch is related to "fc274c1e9973 "USB: gadget: Add a new bus for gadgets".
5.15.y, 5.10.y, 5.5.y and 4.19.y tree doesn't include it, so it's unnecessary. Please drop each tree.

Best regards,
  Nobuhiro

> -----Original Message-----
> From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
> Sent: Tuesday, August 16, 2022 2:56 AM
> To: linux-kernel@xxxxxxxxxxxxxxx
> Cc: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>;
> stable@xxxxxxxxxxxxxxx; Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>;
> syzbot+b0de012ceb1e2a97891b@xxxxxxxxxxxxxxxxxxxxxxxxx
> Subject: [PATCH 5.15 103/779] USB: gadget: Fix use-after-free Read in
> usb_udc_uevent()
> 
> From: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>
> 
> commit 2191c00855b03aa59c20e698be713d952d51fc18 upstream.
> 
> The syzbot fuzzer found a race between uevent callbacks and gadget driver
> unregistration that can cause a use-after-free bug:
> 
> ---------------------------------------------------------------
> BUG: KASAN: use-after-free in usb_udc_uevent+0x11f/0x130
> drivers/usb/gadget/udc/core.c:1732
> Read of size 8 at addr ffff888078ce2050 by task udevd/2968
> 
> CPU: 1 PID: 2968 Comm: udevd Not tainted 5.19.0-rc4-next-20220628-syzkaller
> #0 Hardware name: Google Google Compute Engine/Google Compute Engine,
> BIOS Google
> 06/29/2022
> Call Trace:
>  <TASK>
>  __dump_stack lib/dump_stack.c:88 [inline]
>  dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
> print_address_description mm/kasan/report.c:317 [inline]
>  print_report.cold+0x2ba/0x719 mm/kasan/report.c:433
>  kasan_report+0xbe/0x1f0 mm/kasan/report.c:495
>  usb_udc_uevent+0x11f/0x130 drivers/usb/gadget/udc/core.c:1732
>  dev_uevent+0x290/0x770 drivers/base/core.c:2424
> ---------------------------------------------------------------
> 
> The bug occurs because usb_udc_uevent() dereferences udc->driver but
> does so without acquiring the udc_lock mutex, which protects this field.  If the
> gadget driver is unbound from the udc concurrently with uevent processing,
> the driver structure may be accessed after it has been deallocated.
> 
> To prevent the race, we make sure that the routine holds the mutex around the
> racing accesses.
> 
> Link:
> <https://lore.kernel.org/all/0000000000004de90405a719c951@xxxxxxxxxx>
> CC: stable@xxxxxxxxxxxxxxx # fc274c1e9973
> Reported-and-tested-by:
> syzbot+b0de012ceb1e2a97891b@xxxxxxxxxxxxxxxxxxxxxxxxx
> Signed-off-by: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>
> Link: https://lore.kernel.org/r/YtlrnhHyrHsSky9m@xxxxxxxxxxxxxxxxxxx
> Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
> ---
>  drivers/usb/gadget/udc/core.c |   11 ++++++-----
>  1 file changed, 6 insertions(+), 5 deletions(-)
> 
> --- a/drivers/usb/gadget/udc/core.c
> +++ b/drivers/usb/gadget/udc/core.c
> @@ -1739,13 +1739,14 @@ static int usb_udc_uevent(struct device
>  		return ret;
>  	}
> 
> -	if (udc->driver) {
> +	mutex_lock(&udc_lock);
> +	if (udc->driver)
>  		ret = add_uevent_var(env, "USB_UDC_DRIVER=%s",
>  				udc->driver->function);
> -		if (ret) {
> -			dev_err(dev, "failed to add uevent
> USB_UDC_DRIVER\n");
> -			return ret;
> -		}
> +	mutex_unlock(&udc_lock);
> +	if (ret) {
> +		dev_err(dev, "failed to add uevent USB_UDC_DRIVER\n");
> +		return ret;
>  	}
> 
>  	return 0;