linux-kernel - Re: [PATCH 2/6] staging: rtl8188eu: fix usb_submit

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]

Date:   Tue, 15 Jun 2021 09:47:19 +0300
From:   Dan Carpenter <dan.carpenter@...cle.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Martin Kaiser <martin@...ser.cx>,
        Larry Finger <Larry.Finger@...inger.net>,
        linux-staging@...ts.linux.dev, kernel-janitors@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/6] staging: rtl8188eu: fix usb_submit_urb error handling

On Mon, Jun 14, 2021 at 04:46:41PM +0200, Greg Kroah-Hartman wrote:
> On Sat, Jun 12, 2021 at 08:00:15PM +0200, Martin Kaiser wrote:
> > -EPERM should be handled like any other error.
> 
> Why?  This is not "any other error" for the usb core, right?
> 

Yeah.  It's a fair point that this commit message doesn't say why to do
it or explain the implications.

> > 
> > Suggested-by: Dan Carpenter <dan.carpenter@...cle.com>
> > Signed-off-by: Martin Kaiser <martin@...ser.cx>
> > ---
> >  drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c | 7 +++----
> >  1 file changed, 3 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c b/drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c
> > index ec07b2017fb7..0ceb05f3884f 100644
> > --- a/drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c
> > +++ b/drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c
> > @@ -366,7 +366,6 @@ u32 usb_read_port(struct adapter *adapter, u32 addr, struct recv_buf *precvbuf)
> >  	struct usb_device *pusbd = pdvobj->pusbdev;
> >  	int err;
> >  	unsigned int pipe;
> > -	u32 ret = _SUCCESS;
> >  
> >  	if (adapter->bDriverStopped || adapter->bSurpriseRemoved ||
> >  	    adapter->pwrctrlpriv.pnp_bstop_trx) {
> > @@ -403,10 +402,10 @@ u32 usb_read_port(struct adapter *adapter, u32 addr, struct recv_buf *precvbuf)
> >  			  precvbuf);/* context is precvbuf */
> >  
> >  	err = usb_submit_urb(purb, GFP_ATOMIC);
> > -	if ((err) && (err != (-EPERM)))
> > -		ret = _FAIL;
> 
> if -EPERM returns from this function, someone set the "reject" bit on
> the urb.
> 
> Can this driver do that?  Where did this check originally come from, as
> it feels like this was added for a good reason.
> 

Yeah.  It can cancel urbs in rtw_hal_inirp_deinit().  That function used
to have a better name, "usb_read_port_cancel" and in retrospect the
original name was probably better.

I think the reason for that -EPERM was treated differently was because
originally there were some error messages printed if usb_submit_urb()
failed.  (They were't actually printed because this code is buggy).  The
authors probably didn't want to print the error messages but
accidentally made it return success as well.

There is only one caller that checks the return and it only affects the
behavior if we race against open.  Can that even happen?  I'm pretty
sure that returning a failure is the correct behavior but I'm going to
leave it to Martin to check for absolutely sure.  :P

regards,
dan carpenter