linux-kernel - Re: [PATCH v6 1/5] usb: dwc3: Avoid unmapping USB requests if endxfer is not complete

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] [day] [month] [year] [list]

Date:   Thu, 1 Sep 2022 12:27:12 -0700
From:   Jack Pham <quic_jackp@...cinc.com>
To:     Wesley Cheng <quic_wcheng@...cinc.com>
CC:     <balbi@...nel.org>, <gregkh@...uxfoundation.org>,
        <Thinh.Nguyen@...opsys.com>, <linux-kernel@...r.kernel.org>,
        <linux-usb@...r.kernel.org>
Subject: Re: [PATCH v6 1/5] usb: dwc3: Avoid unmapping USB requests if
 endxfer is not complete

On Thu, Sep 01, 2022 at 12:22:47PM -0700, Jack Pham wrote:
> Hi Wesley,
> 
> On Thu, Sep 01, 2022 at 11:43:10AM -0700, Wesley Cheng wrote:
> > If DWC3_EP_DELAYED_STOP is set during stop active transfers, then do not
> > continue attempting to unmap request buffers during dwc3_remove_requests().
> > This can lead to SMMU faults, as the controller has not stopped the
> > processing of the TRB.  Defer this sequence to the EP0 out start, which
> > ensures that there are no pending SETUP transactions before issuing the
> > endxfer.
> > 
> > Reviewed-by: Thinh Nguyen <Thinh.Nguyen@...opsys.com>
> > Signed-off-by: Wesley Cheng <quic_wcheng@...cinc.com>
> > ---
> >  drivers/usb/dwc3/core.h   | 3 +++
> >  drivers/usb/dwc3/ep0.c    | 5 ++++-
> >  drivers/usb/dwc3/gadget.c | 6 +++++-
> >  3 files changed, 12 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
> > index 4fe4287dc934..7d5d2507244b 100644
> > --- a/drivers/usb/dwc3/core.h
> > +++ b/drivers/usb/dwc3/core.h
> > @@ -1560,6 +1560,7 @@ int dwc3_send_gadget_ep_cmd(struct dwc3_ep *dep, unsigned int cmd,
> >  int dwc3_send_gadget_generic_command(struct dwc3 *dwc, unsigned int cmd,
> >  		u32 param);
> >  void dwc3_gadget_clear_tx_fifos(struct dwc3 *dwc);
> > +void dwc3_remove_requests(struct dwc3 *dwc, struct dwc3_ep *dep, int status);
> >  #else
> >  static inline int dwc3_gadget_init(struct dwc3 *dwc)
> >  { return 0; }
> > @@ -1581,6 +1582,8 @@ static inline int dwc3_send_gadget_generic_command(struct dwc3 *dwc,
> >  { return 0; }
> >  static inline void dwc3_gadget_clear_tx_fifos(struct dwc3 *dwc)
> >  { }
> > +static inline void dwc3_remove_requests(struct dwc3 *dwc, struct dwc3_ep *dep)
> 
> Oops, you missed updating this with the additional 'status' parameter as
> well.

Actually, why even bother having this stub at all? This would only be
when neither CONFIG_USB_DWC3_GADGET nor CONFIG_USB_DWC3_DUAL_ROLE are
enabled, but ep0.c itself wouldn't even be compiled in that case.

Jack