This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] x86-64 memcmp: Use unsigned Jcc instructions on size
- From: Florian Weimer <fweimer at redhat dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Sat, 02 Feb 2019 16:32:54 +0100
- Subject: Re: [PATCH] x86-64 memcmp: Use unsigned Jcc instructions on size
- References: <20190202142723.7730-1-hjl.tools@gmail.com> <87munew85i.fsf@oldenburg2.str.redhat.com> <CAMe9rOpHiDQ+m0JUbr7FYncj=ZfAAyKesG6df+-AK0BLeiphrg@mail.gmail.com>
* H. J. Lu:
> On Sat, Feb 2, 2019 at 6:57 AM Florian Weimer <fweimer@redhat.com> wrote:
>>
>> * H. J. Lu:
>>
>> > Since the size argument is unsigned. we should use unsigned Jcc
>> > instructions, instead of signed to check size.
>> >
>> > Tested on x86-64 and x32, with and without --disable-multi-arch.
>>
>> Does this impact x86-64 at all (technically), consider that an object
>> size larger than SSIZE_MAX would be undefined anyway?
>
> I don't think we will hit it on x86-64.
>
>> It seems that on x32, it can give incorrect results if the sign bit on
>> the 64-bit register is set. In this sense, it is similar to
>> CVE-2019-6488 in impact, right? If we decide to treat this as a
>
> For x32, there is no invalid memory access. It just gives the wrong
> result.
Well, that could be problematic as well.
Does the comparison stop early, only checking a prefix?
>> security vulnerability, we need a new CVE ID because the version range
>> is different (bug 24155 was not fixed in the 2.29 release).
>>
>
> Since the wrong result from memcmp may lead to security vulnerability, we
> should apply for CVE.
Sure, I'll take care of it.
Thanks,
Florian