[PATCH 0/8] x86-64: Properly handle the length parameter [BZ# 24097]

[Florian Weimer]

* H. J. Lu:

> On Fri, Jan 18, 2019 at 11:56 AM Florian Weimer <fweimer@redhat.com> wrote:
>>
>> * H. J. Lu:
>>
>> > On Fri, Jan 18, 2019 at 2:50 AM Florian Weimer <fweimer@redhat.com> wrote:
>> >>
>> >> * H. J. Lu:
>> >>
>> >> > On x32, the size_t parameter may be passed in the lower 32 bits of a
>> >> > 64-bit register with the non-zero upper 32 bits.  The string/memory
>> >> > functions written in assembly can only use the lower 32 bits of a
>> >> > 64-bit register as length or must clear the upper 32 bits before using
>> >> > the full 64-bit register for length.
>> >> >
>> >> > This pach fixes string/memory functions written in assembly for x32.
>> >> > Tested on x86-64 and x32.  On x86-64, libc.so is the same with and
>> >> > withou the fix.
>> >>
>> >> Can this bug result in buffer overflows?  Should we obtain a CVE
>> >
>> > Yes, definitely.
>> >
>> >> identifier?
>> >>
>> >
>> > Yes, please.  Can you do that for me?
>>
>> Done, MITRE gave us CVE-2019-6488.  Please reference this in the
>> ChangeLog and the commit message if you have not done so.  Please also
>
> Done.  I just regenerated and submitted the new patch set.
>
>> add short NEWS entry in the security section.  Thanks.
>>
>
> I added:
>
>   CVE-2019-6488: On x32, the size_t parameter may be passed in the lower
>   32 bits of a 64-bit register with the non-zero upper 32 bits.  When
>   it happens, the string/memory functions written in assembly will cause
>   buffer overflow if the full 64-bit register is used as the 32-bit

I think we generally describe the faulty behavior in the past tense
(“When this happen*ed*, the string/memory functions written in assembly
*would* cause *a* buffer overflow if the full 64-bit register was
used”).  The first sentence is still current behavior, so it's okay.

>   size_t value.  Reported by Florian Weimer.

Huh.  Did I really report this?  When?

Thanks,
Florian