linux-kernel - Re: BUG/OOPS: Double Lock in fsl_usb2

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 May 2008 02:23:39 -0700
From:	David Brownell <david-b@...bell.net>
To:	Eugene_Bordenkircher@...inc.com
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org,
	Li Yang <leoli@...escale.com>
Subject: Re: BUG/OOPS: Double Lock in fsl_usb2_udc.c

> On Wed, 28 May 2008 15:25:31 -0700 Eugene_Bordenkircher@...inc.com wrote:
> 
> > Looking through other drivers, I have seen them releasing the lock 
> > immediately before calling disconnect(), however, without being an expert 
> > with this driver, I'm not entirely sure that is the best option here. 

Yeah, general policy is to drop the UDC spinlock whenever
you call out to gadget driver code, since it may need to
reenter for various reasons.  (Though if drivers adopt some
other locking policy that works, that should be fine too.
Multiple locks don't seem to be needed.)

If this particular UDC driver doesn't let disconnect()
disable the endpoints, that's a bug.  All gadget drivers
should clean up on disconnect; and while the UDC code
ought to have aborted any pending I/Os, it should never
be disabling things the gadget driver enabled.

And as for calling disconnect() before proceeding with
enumeration ... if the UDC driver can sense disconnect
(most often done with a GPIO hooked up to provide IRQs
on VBUS edge transitions), it should do so then.  But
for boards that don't have VBUS sensing, then the only
hook to scrub out all the old/invalid connection state
is the USB reset sequence that starts enumeration.  And
that's what seems to be happening here.

- Dave
--
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/