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 0/8] x86-64: Properly handle the length parameter [BZ# 24097]


On Fri, Jan 18, 2019 at 12:40 PM Florian Weimer <fweimer@redhat.com> wrote:
>
> * H. J. Lu:
>
> > On Fri, Jan 18, 2019 at 12:21 PM Florian Weimer <fweimer@redhat.com> wrote:
> >>
> >> * 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.
> >
> > Like this?
> >
> >   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
>
> “with non-zero upper 32 bits”
>
> >   it happened, the string/memory functions written in assembly would
> >   cause a buffer overflow if the full 64-bit register was used as the
>
> Hmm.  Maybe “because the full”?
>
> >   32-bit size_t value.  Reported by H.J. Lu.
>
> Rest of this descriptions looks okay to me.  (Not a native speaker.)
>

Now it has:

  CVE-2019-6488: On x32, the size_t parameter may be passed in the lower
  32 bits of a 64-bit register with with non-zero upper 32 bit.  When it
  happened, the string/memory functions written in assembly would cause a
  buffer overflow because the full 64-bit register was used as the 32-bit
  size_t value.  Reported by H.J. Lu.

Thanks.

-- 
H.J.


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