2016-05-18 11:18 GMT+03:00 Oliver Neukum <oneukum@xxxxxxxx>:
> On Wed, 2016-05-18 at 10:40 +0300, Andrey Ryabinin wrote:
>> 2016-05-18 1:16 GMT+03:00 Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>:
>> > 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;
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
