linux-kernel - Re: [PATCH v10 2/6] usb: gadget: configfs: Check USB configuration before adding

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: <YNF9kv0kWAz6Pp00@kroah.com>
Date:   Tue, 22 Jun 2021 08:05:07 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Wesley Cheng <wcheng@...eaurora.org>
Cc:     balbi@...nel.org, robh+dt@...nel.org, agross@...nel.org,
        bjorn.andersson@...aro.org, frowand.list@...il.com,
        linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        jackp@...eaurora.org, fntoth@...il.com,
        heikki.krogerus@...ux.intel.com, andy.shevchenko@...il.com
Subject: Re: [PATCH v10 2/6] usb: gadget: configfs: Check USB configuration
 before adding

On Mon, Jun 21, 2021 at 10:27:09PM -0700, Wesley Cheng wrote:
> 
> 
> On 6/17/2021 4:07 AM, Greg KH wrote:
> > On Thu, Jun 17, 2021 at 02:58:15AM -0700, Wesley Cheng wrote:
> >> Ensure that the USB gadget is able to support the configuration being
> >> added based on the number of endpoints required from all interfaces.  This
> >> is for accounting for any bandwidth or space limitations.
> >>
> >> Signed-off-by: Wesley Cheng <wcheng@...eaurora.org>
> >> ---
> >>  drivers/usb/gadget/configfs.c | 22 ++++++++++++++++++++++
> >>  1 file changed, 22 insertions(+)
> >>
> >> diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
> >> index 15a607c..76b9983 100644
> >> --- a/drivers/usb/gadget/configfs.c
> >> +++ b/drivers/usb/gadget/configfs.c
> >> @@ -1374,6 +1374,7 @@ static int configfs_composite_bind(struct usb_gadget *gadget,
> >>  		struct usb_function *f;
> >>  		struct usb_function *tmp;
> >>  		struct gadget_config_name *cn;
> >> +		unsigned long ep_map = 0;
> >>  
> >>  		if (gadget_is_otg(gadget))
> >>  			c->descriptors = otg_desc;
> >> @@ -1403,7 +1404,28 @@ static int configfs_composite_bind(struct usb_gadget *gadget,
> >>  				list_add(&f->list, &cfg->func_list);
> >>  				goto err_purge_funcs;
> >>  			}
> >> +			if (f->fs_descriptors) {
> >> +				struct usb_descriptor_header **d;
> >> +
> >> +				d = f->fs_descriptors;
> >> +				for (; *d; ++d) {
> 
> Hi Greg,
> 
> Thanks for the review and feedback.
> 
> > 
> > With this check, there really is not a need to check for
> > f->fs_descriptors above in the if statement, right?
> > 
> 
> f->fs_descriptor will carry the table of descriptors that a particular
> function driver has assigned to it.  The for loop here, will dereference
> the individual descriptors within that descriptor array, so we need to
> first ensure the descriptor array is present before traversing through
> the individual entries/elements.

Ah, it's a dereference of an array element.  Subtle.  Tricky.  Messy :(

> >> +					struct usb_endpoint_descriptor *ep;
> >> +					int addr;
> >> +
> >> +					if ((*d)->bDescriptorType != USB_DT_ENDPOINT)
> >> +						continue;
> >> +
> >> +					ep = (struct usb_endpoint_descriptor *)*d;
> >> +					addr = ((ep->bEndpointAddress & 0x80) >> 3) |
> >> +						(ep->bEndpointAddress & 0x0f);
> > 
> > Don't we have direction macros for this type of check?
> > 
> 
> I don't believe we have a macro which would be able to convert the
> bEndpointAddress field into the bit which needs to be set, assuming that
> the 32bit ep_map has the lower 16bits carrying OUT EPs, and the upper
> 16bits carrying the IN EPs.

We have macros to tell if an endpoint is IN or OUT, please use those.

And this "cram the whole thing into 64 bits" is not obvious at all.
Just pass around the original pointer to the descriptors if someone
wants to use it or not, don't make up yet-another-data-structure here
for no good reason.  We aren't so memory constrained we need to pack
stuff into bits here.

thanks,

greg k-h