linux-kernel - Re: [PATCH] - silence UBSAN complaint in ehci-hcd.

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:	Fri, 20 May 2016 10:37:22 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Valdis.Kletnieks@...edu
cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Andrey Ryabinin <ryabinin.a.a@...il.com>,
	Oliver Neukum <oneukum@...e.com>,
	<linux-kernel@...r.kernel.org>, <linux-usb@...r.kernel.org>
Subject: Re: [PATCH] - silence UBSAN complaint in ehci-hcd.

On Thu, 19 May 2016 Valdis.Kletnieks@...edu wrote:

> On Thu, 19 May 2016 17:50:31 -0700, Greg Kroah-Hartman said:
> > On Thu, May 19, 2016 at 05:19:00PM -0400, Valdis Kletnieks wrote:
> > > UBSAN throws a complaint:
> > >
> > > [    2.418579] UBSAN: Undefined behaviour in drivers/usb/host/ehci-hub.c:877:47
> > > [    2.418582] index -1 is out of range for type 'u32 [1]'
> > >
> > > though it's only on the hostpc[] part, not  on the port_status[] on the
> > > previous line which has the same exact index calculation.  The root cause is
> > > that the first declaration is port_status[0], which uses a GCC extension and
> > > UBSAN is smart enough to realize the programmer is doing something
> > > intentionally odd.
> > >
> > > However, the problematic declaration is hostpc[1], which doesn't have
> > > the "I know what I'm doing" semantics of [0].  Change the declaration to match.
> > >
> > > Signed-Off-By: Valdis Kletnieks <valdis.kletnieks@...edu>
> > >
> > > --- a/include/linux/usb/ehci_def.h	2015-01-06 01:04:24.342436706 -0500
> > > +++ b/include/linux/usb/ehci_def.h	2016-05-19 13:57:20.869304540 -0400
> > > @@ -180,11 +180,11 @@ struct ehci_regs {
> > >   * PORTSCx
> > >   */
> > >  	/* HOSTPC: offset 0x84 */
> > > -	u32		hostpc[1];	/* HOSTPC extension */
> > > +	u32		hostpc[0];	/* HOSTPC extension */
> > >  #define HOSTPC_PHCD	(1<<22)		/* Phy clock disable */
> > >  #define HOSTPC_PSPD	(3<<25)		/* Port speed detection */
> >
> > Hm, this is odd, you really do want hostpc to be 1 u32 value, don't make
> > it 0 please.  If you walk off the end of hostpc, well, let's fix that
> > properly.
> 
> Well, UBSAN doesn't complain about the *other* use of the same exact index,
> apparently because 'u32 port_status[0]' tells it to shut up we know what we're
> doing.
> 
> And I'm pretty sure that if hostpc was supposed to be exactly one u32 rather
> than an array, it wouldn't have the [] semantics everyplace...

hostpc is supposed to have the same number of elements as the number of 
ports.  (On the other hand, I'm not sure if any of the platforms which 
implement the hostpc register have more than one port...)

Alan Stern