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:   Thu, 29 Jun 2017 14:10:35 -0400 (EDT)
From:   Alan Stern <stern@...land.harvard.edu>
To:     Ben Hutchings <ben.hutchings@...ethink.co.uk>
cc:     linux-kernel@...r.kernel.org, <stable@...r.kernel.org>,
        Felipe Balbi <felipe.balbi@...ux.intel.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH 4.4 22/30] USB: gadgetfs, dummy-hcd, net2280: fix locking
 for callbacks

On Thu, 29 Jun 2017, Ben Hutchings wrote:

> On Mon, 2017-06-19 at 23:20 +0800, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch.  If anyone has any objections, please let me know.
> > 
> > ------------------
> > 
> > From: Alan Stern <stern@...land.harvard.edu>
> > 
> > commit f16443a034c7aa359ddf6f0f9bc40d01ca31faea upstream.
> [...]
> > The result of this race, as seen above, is that set_link_state() can
> > invoke a callback in gadgetfs even after gadgetfs has been unbound
> > from dummy_hcd's UDC and its private data structures have been
> > deallocated.
> > 
> > include/linux/usb/gadget.h documents that the ->reset, ->disconnect,
> > ->suspend, and ->resume callbacks may be invoked in interrupt context.
> > In general this is necessary, to prevent races with gadget driver
> > removal.  This patch fixes dummy_hcd to retain the spinlock across
> > these calls, and it adds a spinlock acquisition to dummy_udc_stop() to
> > prevent the race.
> > 
> > The net2280 driver makes the same mistake of dropping the private
> > spinlock for its ->disconnect and ->reset callback invocations.  The
> > patch fixes it too.
> [...]
> 
> Why only these two drivers?  Most of the other UDC drivers seem to do
> the same thing.

I'm not at all familiar with the other UDC drivers, only those two.

If the maintainers for other UDC drivers would like to discuss the
problem and consider whether changes are needed, I'd be glad to help.

Alan Stern

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ