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 Sat, Jan 19, 2019 at 7:13 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Sat, Jan 19, 2019 at 2:38 AM Florian Weimer <fweimer@redhat.com> wrote:
> >
> > * Rical Jasan:
> >
> > > On 01/18/2019 12:47 PM, H.J. Lu wrote:
> > >> 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.
> > >
> > > How about:
> > >
> > > CVE-2019-6488: On x32, the size_t parameter may be passed in the lower
> > > 32 bits of a 64-bit register with non-zero upper 32 bits, causing a
> > > buffer overflow in string and memory functions written in assembly when
> > > the full 64-bit register was used as the 32-bit size_t value.
> >
> > The problem is not the first part (the undefined upper half of the
> > register, that's part of the ABI).  It's that the string functions did
> > not account for this ABI property.
> >
>
> How about this one?
>
>   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, accessing the 32-bit size_t value as the full 64-bit register
>   in the assembly string/memory functions would cause a buffer overflow.
>   Reported by H.J. Lu.

If there are no objections, I will check in my fixes tomorrow.

-- 
H.J.


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