[LTP] [PATCH] kill13, CVE-2018-10124: Reproduce INT_MIN negation

[Joerg Vehlow]

Hi Richard,

On 7/7/2021 12:01 PM, Richard Palethorpe wrote:
> Hello Joerg,
>
> Joerg Vehlow <lkml@jv-coder.de> writes:
>
>> Hi,
>>
>> On 7/7/2021 10:35 AM, Joerg Vehlow wrote:
>>> Hi Richard,
>>>
>>> On 7/7/2021 9:18 AM, Richard Palethorpe via ltp wrote:
>>> Results in INT_MIN? What does this mean or did you meant to write
>>> results in ESRCH?
>>> Default negating int min in two's complement yields 0 (INT_MIN =
>>> b1000... and negating means inverting the first bit -> thus 0).
>> Nevermind... Just checked. Looks like somehow x86 keeps -INT_MIN.
>> Now I know what you mean with "results in INT_MIN"
>>
>> Joerg
> Actually this seems to be expected unless the CPU takes action to prvent
> it. As you invert all the bits then add one in two's complement. So
> inverting results in INT_MAX then we add one and overflow back to
> INT_MIN.
Ahh yes totally had the wrong model of * -1 in my head... Of course it 
is invert everything and add +1.
That of course means -INT_MIN == INT_MIN.

>
> It is undefined though so the CPU could decide to do something
> else. OTOH it seems quite unlikely we will get anything other than
> INT_MIN or INT_MAX. So I will set sig number to zero as you suggested
> and we will just have to rely on UBSAN.
With this change:
Acked-by: Joerg Vehlow <joerg.vehlow@aox-tech.de>

Jörg