linux-kernel - Re: [PATCH] usb: dwc3: ep0: fix delayed status is queued too early

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 7 May 2014 12:59:06 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Zhuang Jin Can <jin.can.zhuang@...el.com>
cc:	Felipe Balbi <balbi@...com>, USB list <linux-usb@...r.kernel.org>,
	<linux-omap@...r.kernel.org>,
	Kernel development list <linux-kernel@...r.kernel.org>,
	<liping.zhou@...el.com>, <david.a.cohen@...ux.intel.com>
Subject: Re: [PATCH] usb: dwc3: ep0: fix delayed status is queued too early

On Thu, 8 May 2014, Zhuang Jin Can wrote:

> > A similar problem can occur in the opposite sense: The thread queuing
> > the delayed status request might be delayed for so long that another
> > SETUP packet arrives from the host first.  In that case, the delayed
> > status request is a response for a stale transfer, so it must not be
> > sent to the host.
> > 
> > Do dwc3 and composite.c handle this case correctly?
> > 
> So the situation you describe is that we get the STATUS XferNotReady
> event, but gadget queues a status request when control transfer already
> failed.

When the host already timed out the control transfer and started a new 
one.  Here's what I'm talking about:

	Host sends a Set-Configuration request.

	The UDC driver calls the gadget driver's setup function.

	The setup function returns DELAYED_STATUS.

	After a few seconds, the host gets tired of waiting and
	sends a Get-Descriptor request

	The gadget driver finally submits the delayed request response
	to the Set-Configuration request.  But it is now too late,
	because the host expects a response to the Get-Descriptor 
	request.

>  dwc3 can't move to SETUP phase until the status request arrives,
> so any SETUP transaction from host will fail. If status request
> eventually arrives, it already missed the first control transfer, and
> I don't know how the controller will behave. If we still can get a
> STATUS XferComplete event without actually transfer anything on the
> bus, then we can move back to SETUP PHASE which will remove the stale
> delayed status request and start the new SETUP transaction. But I think
> in this situation, the host should already lose it patience and start
> to reset the bus.

My point is that the UDC driver can't handle this.  Therefore the
gadget driver has to prevent this from happening.

That means composite.c has to avoid sending delayed status responses if 
a new SETUP packet has been received already.

> Per my understanding, it's impossible for dwc3 to send a stale STATUS
> request for a new SETUP transaction. 

dwc3 won't know that the status response is stale.  It will think the 
response was meant for the new transfer, not the old one.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/