linux-kernel - Re: UBSAN whinge in ihci-hub.c

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:	Wed, 18 May 2016 12:16:28 +0300
From:	Andrey Ryabinin <ryabinin.a.a@...il.com>
To:	Oliver Neukum <oneukum@...e.com>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Alan Stern <stern@...land.harvard.edu>,
	LKML <linux-kernel@...r.kernel.org>, linux-usb@...r.kernel.org,
	Valdis Kletnieks <Valdis.Kletnieks@...edu>
Subject: Re: UBSAN whinge in ihci-hub.c

2016-05-18 11:18 GMT+03:00 Oliver Neukum <oneukum@...e.com>:
> On Wed, 2016-05-18 at 10:40 +0300, Andrey Ryabinin wrote:
>> 2016-05-18 1:16 GMT+03:00 Greg Kroah-Hartman <gregkh@...uxfoundation.org>:
>> > On Tue, May 17, 2016 at 05:52:40PM -0400, Valdis Kletnieks wrote:
>> >> So, not content in the amount of breakage I generate already, I
>> >> compiled with UBSAN enabled...
>> >>
>> >> The immediately relevant part:
>> >>
>> >> [    2.418576] ================================================================================
>> >> [    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]'
>> >
>> > <snip>
>> >
>> > It's a known bug in ubsan,
>>
>> It's not a bug.  int *p = &a[-1] is undefined behavior. It doesn't
>> matter whether that pointer dereferenced or not.
>
> That is a bold statement. Pointer arithmetic is defined. How can
> the computation of an address be undefined behavior while it is
> not used?

It's defined only if pointer points to array element or one-past-end
element. Everything else is undefined.

$ 6.5.6.8
   "If both the pointer operand and the result point to elements of
the same array object,
     or one past the last element of the array object, the evaluation
shall not produce an overflow;
     otherwise, the behavior is undefined."

Here is a good example of how bad this could be -
https://lwn.net/Articles/278137/

So, in case of ehci_hub_control(), gcc is allowed to assume that
wIndex is never 0, and
"optimize" away !wIndex check from this code:

   if (!wIndex || wIndex > ports)
        goto error;