This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] x86-64 memcmp: Use unsigned Jcc instructions on size


On Sat, Feb 2, 2019 at 7:32 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> * 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?

On x32, memcmp always returns 0 when the most significant bit of RDX is set
since it treats size as 0, like memcmp (a, b, 0).

> >> 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.


-- 
H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]