[PATCH] usb: gadget: core: Check for unset descriptor

[PATCH] usb: gadget: core: Check for unset descriptor

[crwulff]

From: Chris Wulff <crwulff@gmail.com>

Make sure the descriptor has been set before looking at maxpacket.
This fixes a null pointer panic in this case.

This may happen if the gadget doesn't properly set up the endpoint
for the current speed, or the gadget descriptors are malformed and
the descriptor for the speed/endpoint are not found.

Fixes: 54f83b8c8ea9 ("USB: gadget: Reject endpoints with 0 maxpacket value")
Cc: stable@vger.kernel.org
Signed-off-by: Chris Wulff <crwulff@gmail.com>
---
 drivers/usb/gadget/udc/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c
index 2dfae7a17b3f..36a5d5935889 100644
--- a/drivers/usb/gadget/udc/core.c
+++ b/drivers/usb/gadget/udc/core.c
@@ -118,7 +118,7 @@ int usb_ep_enable(struct usb_ep *ep)
 		goto out;
 
 	/* UDC drivers can't handle endpoints with maxpacket size 0 */
-	if (usb_endpoint_maxp(ep->desc) == 0) {
+	if (!ep->desc || usb_endpoint_maxp(ep->desc) == 0) {
 		/*
 		 * We should log an error message here, but we can't call
 		 * dev_err() because there's no way to find the gadget
-- 
2.43.0

Re: [PATCH] usb: gadget: core: Check for unset descriptor

[Alan Stern]

On Sun, Jul 21, 2024 at 03:20:49PM -0400, crwulff@gmail.com wrote:
> From: Chris Wulff <crwulff@gmail.com>
> 
> Make sure the descriptor has been set before looking at maxpacket.
> This fixes a null pointer panic in this case.
> 
> This may happen if the gadget doesn't properly set up the endpoint
> for the current speed, or the gadget descriptors are malformed and
> the descriptor for the speed/endpoint are not found.

If that happens, doesn't it mean there's a bug in the gadget driver?  
And if there's a bug, don't we want to be told about it by a big 
impossible-to-miss error message, so the bug can be fixed?

> Fixes: 54f83b8c8ea9 ("USB: gadget: Reject endpoints with 0 maxpacket value")
> Cc: stable@vger.kernel.org
> Signed-off-by: Chris Wulff <crwulff@gmail.com>
> ---
>  drivers/usb/gadget/udc/core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c
> index 2dfae7a17b3f..36a5d5935889 100644
> --- a/drivers/usb/gadget/udc/core.c
> +++ b/drivers/usb/gadget/udc/core.c
> @@ -118,7 +118,7 @@ int usb_ep_enable(struct usb_ep *ep)
>  		goto out;
>  
>  	/* UDC drivers can't handle endpoints with maxpacket size 0 */
> -	if (usb_endpoint_maxp(ep->desc) == 0) {
> +	if (!ep->desc || usb_endpoint_maxp(ep->desc) == 0) {
>  		/*
>  		 * We should log an error message here, but we can't call
>  		 * dev_err() because there's no way to find the gadget

This will just hide the error.  That's not good.

Alan Stern

Re: [PATCH] usb: gadget: core: Check for unset descriptor

[Chris Wulff]

On Sun, Jul 21, 2024 at 9:07 PM Alan Stern <stern@rowland.harvard.edu> wrote:
>
> On Sun, Jul 21, 2024 at 03:20:49PM -0400, crwulff@gmail.com wrote:
> > From: Chris Wulff <crwulff@gmail.com>
> >
> > Make sure the descriptor has been set before looking at maxpacket.
> > This fixes a null pointer panic in this case.
> >
> > This may happen if the gadget doesn't properly set up the endpoint
> > for the current speed, or the gadget descriptors are malformed and
> > the descriptor for the speed/endpoint are not found.
>
> If that happens, doesn't it mean there's a bug in the gadget driver?
> And if there's a bug, don't we want to be told about it by a big
> impossible-to-miss error message, so the bug can be fixed?

Yes, this is an indicator of a problem in a gadget driver as was the
previous check for a zero max packet size. In this case, the panic
is in an interrupt context and it doesn't make it out to the console.
This just results in a system freeze without this fix.

>
> > Fixes: 54f83b8c8ea9 ("USB: gadget: Reject endpoints with 0 maxpacket value")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Chris Wulff <crwulff@gmail.com>
> > ---
> >  drivers/usb/gadget/udc/core.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c
> > index 2dfae7a17b3f..36a5d5935889 100644
> > --- a/drivers/usb/gadget/udc/core.c
> > +++ b/drivers/usb/gadget/udc/core.c
> > @@ -118,7 +118,7 @@ int usb_ep_enable(struct usb_ep *ep)
> >               goto out;
> >
> >       /* UDC drivers can't handle endpoints with maxpacket size 0 */
> > -     if (usb_endpoint_maxp(ep->desc) == 0) {
> > +     if (!ep->desc || usb_endpoint_maxp(ep->desc) == 0) {
> >               /*
> >                * We should log an error message here, but we can't call
> >                * dev_err() because there's no way to find the gadget
>
> This will just hide the error.  That's not good.

The previous check was also hiding the error, and introduced a panic.
I could add a printk to that error case, though it would be unassociated
with the gadget that caused the problem. This function does also return
an error code when it fails, so the calling function can check that and
print an error.

>
> Alan Stern

Re: [PATCH] usb: gadget: core: Check for unset descriptor

[Alan Stern]

On Mon, Jul 22, 2024 at 09:00:07AM -0400, Chris Wulff wrote:
> On Sun, Jul 21, 2024 at 9:07 PM Alan Stern <stern@rowland.harvard.edu> wrote:
> >
> > On Sun, Jul 21, 2024 at 03:20:49PM -0400, crwulff@gmail.com wrote:
> > > From: Chris Wulff <crwulff@gmail.com>
> > >
> > > Make sure the descriptor has been set before looking at maxpacket.
> > > This fixes a null pointer panic in this case.
> > >
> > > This may happen if the gadget doesn't properly set up the endpoint
> > > for the current speed, or the gadget descriptors are malformed and
> > > the descriptor for the speed/endpoint are not found.
> >
> > If that happens, doesn't it mean there's a bug in the gadget driver?
> > And if there's a bug, don't we want to be told about it by a big
> > impossible-to-miss error message, so the bug can be fixed?
> 
> Yes, this is an indicator of a problem in a gadget driver as was the
> previous check for a zero max packet size. In this case, the panic
> is in an interrupt context and it doesn't make it out to the console.
> This just results in a system freeze without this fix.
> 
> >
> > > Fixes: 54f83b8c8ea9 ("USB: gadget: Reject endpoints with 0 maxpacket value")
> > > Cc: stable@vger.kernel.org
> > > Signed-off-by: Chris Wulff <crwulff@gmail.com>
> > > ---
> > >  drivers/usb/gadget/udc/core.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c
> > > index 2dfae7a17b3f..36a5d5935889 100644
> > > --- a/drivers/usb/gadget/udc/core.c
> > > +++ b/drivers/usb/gadget/udc/core.c
> > > @@ -118,7 +118,7 @@ int usb_ep_enable(struct usb_ep *ep)
> > >               goto out;
> > >
> > >       /* UDC drivers can't handle endpoints with maxpacket size 0 */
> > > -     if (usb_endpoint_maxp(ep->desc) == 0) {
> > > +     if (!ep->desc || usb_endpoint_maxp(ep->desc) == 0) {
> > >               /*
> > >                * We should log an error message here, but we can't call
> > >                * dev_err() because there's no way to find the gadget
> >
> > This will just hide the error.  That's not good.
> 
> The previous check was also hiding the error, and introduced a panic.
> I could add a printk to that error case, though it would be unassociated
> with the gadget that caused the problem. This function does also return
> an error code when it fails, so the calling function can check that and
> print an error.

Okay.  It wouldn't hurt to print out an error message, even if there's 
no way to tell which gadget it refers to.  A dump_stack() would help in 
that regard, but it won't be needed if the guilty party will always be 
pretty obvious.

By the way, how did you manage to trigger this error?  None of the 
in-kernel gadget drivers are known to have this bug, and both the 
gadgetfs and raw_gadget drivers prevent userspace from doing it.  Were 
you testing a gadget driver that was under development?

Alan Stern

Re: [PATCH] usb: gadget: core: Check for unset descriptor

[Chris Wulff]

On Mon, Jul 22, 2024 at 9:38 AM Alan Stern <stern@rowland.harvard.edu> wrote:
>
> On Mon, Jul 22, 2024 at 09:00:07AM -0400, Chris Wulff wrote:
> > On Sun, Jul 21, 2024 at 9:07 PM Alan Stern <stern@rowland.harvard.edu> wrote:
> > >
> > > On Sun, Jul 21, 2024 at 03:20:49PM -0400, crwulff@gmail.com wrote:
> > > > From: Chris Wulff <crwulff@gmail.com>
...
> > The previous check was also hiding the error, and introduced a panic.
> > I could add a printk to that error case, though it would be unassociated
> > with the gadget that caused the problem. This function does also return
> > an error code when it fails, so the calling function can check that and
> > print an error.
>
> Okay.  It wouldn't hurt to print out an error message, even if there's
> no way to tell which gadget it refers to.  A dump_stack() would help in
> that regard, but it won't be needed if the guilty party will always be
> pretty obvious.
>
> By the way, how did you manage to trigger this error?  None of the
> in-kernel gadget drivers are known to have this bug, and both the
> gadgetfs and raw_gadget drivers prevent userspace from doing it.  Were
> you testing a gadget driver that was under development?

I am working on adding alternate settings to UAC1/2 gadgets, so this really
was a case of trying to make the failure in development easier to deal with.
I don't believe there are any problems with existing gadgets causing this.

I will add an error message and submit a new version. Perhaps
WARN_ON_ONCE would be appropriate here to get that backtrace
instead of a printk?

>
> Alan Stern

Re: [PATCH] usb: gadget: core: Check for unset descriptor

[Alan Stern]

On Mon, Jul 22, 2024 at 01:11:01PM -0400, Chris Wulff wrote:
> On Mon, Jul 22, 2024 at 9:38 AM Alan Stern <stern@rowland.harvard.edu> wrote:
> >
> > On Mon, Jul 22, 2024 at 09:00:07AM -0400, Chris Wulff wrote:
> > > On Sun, Jul 21, 2024 at 9:07 PM Alan Stern <stern@rowland.harvard.edu> wrote:
> > > >
> > > > On Sun, Jul 21, 2024 at 03:20:49PM -0400, crwulff@gmail.com wrote:
> > > > > From: Chris Wulff <crwulff@gmail.com>
> ...
> > > The previous check was also hiding the error, and introduced a panic.
> > > I could add a printk to that error case, though it would be unassociated
> > > with the gadget that caused the problem. This function does also return
> > > an error code when it fails, so the calling function can check that and
> > > print an error.
> >
> > Okay.  It wouldn't hurt to print out an error message, even if there's
> > no way to tell which gadget it refers to.  A dump_stack() would help in
> > that regard, but it won't be needed if the guilty party will always be
> > pretty obvious.
> >
> > By the way, how did you manage to trigger this error?  None of the
> > in-kernel gadget drivers are known to have this bug, and both the
> > gadgetfs and raw_gadget drivers prevent userspace from doing it.  Were
> > you testing a gadget driver that was under development?
> 
> I am working on adding alternate settings to UAC1/2 gadgets, so this really
> was a case of trying to make the failure in development easier to deal with.
> I don't believe there are any problems with existing gadgets causing this.
> 
> I will add an error message and submit a new version. Perhaps
> WARN_ON_ONCE would be appropriate here to get that backtrace
> instead of a printk?

That sounds good.  You should also mention in the patch description that 
the purpose is to prevent undebuggable panics during driver development, 
and no existing drivers will trigger the warning.

Alan Stern