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] [thread-next>] [day] [month] [year] [list]
Message-ID: <fbf87ddf-6d8e-43b7-b9f5-65025395b170@rowland.harvard.edu>
Date: Sat, 31 Aug 2024 00:29:02 -0400
From: Alan Stern <stern@...land.harvard.edu>
To: Selvarasu Ganesan <selvarasu.g@...sung.com>
Cc: Greg KH <gregkh@...uxfoundation.org>, royluo@...gle.com,
	paul@...pouillou.net, elder@...nel.org, yuanlinyu@...onor.com,
	quic_kriskura@...cinc.com, crwulff@...il.com,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
	jh0801.jung@...sung.com, dh10.jung@...sung.com, naushad@...sung.com,
	akash.m5@...sung.com, rc93.raju@...sung.com,
	taehyun.cho@...sung.com, hongpooh.kim@...sung.com,
	eomji.oh@...sung.com, shijie.cai@...sung.com,
	stable <stable@...nel.org>
Subject: Re: [PATCH] usb: gadget: udc: Add null pointer check for udc in
 gadget_match_driver

On Fri, Aug 30, 2024 at 06:16:12PM +0530, Selvarasu Ganesan wrote:
> Hi Alan,
> 
> Thanks for your comments. I understand your suggestions. We already have 
> a similar reference check with the udc name before calling 
> usb_gadget_register_driver.
> In the drivers/usb/gadget/configfs.c file, I am wondering if there might 
> be an issue with the check of udc_name before 
> usb_gadget_register_driver. This is the only way to allow 
> gadget_register to be called before releasing or unregistering an 
> existing udc. Do you think we need to add an additional check here, 
> referencing the UDC, to prevent gadget_register from being called before 
> the existing UDC is released?

I don't understand what you're saying.  There is no routine named 
"gadget_register".  (And there is no variable named "udc_name" in the 
code below, although there is gi->composite.gadget_driver.udc_name -- 
but that's not a variable, it is a field in a structure.)

> drivers/usb/gadget/configfs.c : gadget_dev_desc_UDC_store()
> ===========================================================
> if (gi->composite.gadget_driver.udc_name) {
>                          ret = -EBUSY;
>                          goto err;
>                  }
> gi->composite.gadget_driver.udc_name = name;

Are you talking about this check and assignment?  Why do you think there 
might be a problem here?

Are you worried that some UDC might be released while this code is 
running?  If that happens, why would it be a problem?

> ret = usb_gadget_register_driver(&gi->composite.gadget_driver);

Alan Stern

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ