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

Message ID 20190117165351.25914-1-hjl.tools@gmail.com
Headers show
Series
  • x86-64: Properly handle the length parameter [BZ# 24097]
Related show

Message

H.J. Lu Jan. 17, 2019, 4:53 p.m.
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.

H.J. Lu (8):
  x86-64 memchr/wmemchr: Properly handle the length parameter [BZ#
    24097]
  x86-64 memcmp/wmemcmp: Properly handle the length parameter [BZ#
    24097]
  x86-64 memcpy: Properly handle the length parameter [BZ# 24097]
  x86-64 memrchr: Properly handle the length parameter [BZ# 24097]
  x86-64 memset/wmemset: Properly handle the length parameter [BZ#
    24097]
  x86-64 strncmp family: Properly handle the length parameter [BZ#
    24097]
  x86-64 strncpy: Properly handle the length parameter [BZ# 24097]
  x86-64 strnlen/wcsnlen: Properly handle the length parameter [BZ#
    24097]

 sysdeps/x86_64/memchr.S                       |  10 +-
 sysdeps/x86_64/memrchr.S                      |   4 +-
 sysdeps/x86_64/multiarch/memchr-avx2.S        |   8 +-
 sysdeps/x86_64/multiarch/memcmp-avx2-movbe.S  |   7 +-
 sysdeps/x86_64/multiarch/memcmp-sse4.S        |   9 +-
 sysdeps/x86_64/multiarch/memcmp-ssse3.S       |   7 +-
 sysdeps/x86_64/multiarch/memcpy-ssse3-back.S  |  17 +-
 sysdeps/x86_64/multiarch/memcpy-ssse3.S       |  17 +-
 .../multiarch/memmove-avx512-no-vzeroupper.S  |  16 +-
 .../multiarch/memmove-vec-unaligned-erms.S    |  54 +++---
 sysdeps/x86_64/multiarch/memrchr-avx2.S       |   4 +-
 .../multiarch/memset-avx512-no-vzeroupper.S   |   6 +-
 .../multiarch/memset-vec-unaligned-erms.S     |  34 ++--
 sysdeps/x86_64/multiarch/strcmp-avx2.S        |   6 +-
 sysdeps/x86_64/multiarch/strcmp-sse42.S       |   6 +-
 sysdeps/x86_64/multiarch/strcpy-avx2.S        |   4 +-
 .../x86_64/multiarch/strcpy-sse2-unaligned.S  |   4 +-
 sysdeps/x86_64/multiarch/strcpy-ssse3.S       |   6 +-
 sysdeps/x86_64/multiarch/strlen-avx2.S        |   9 +-
 sysdeps/x86_64/strcmp.S                       |   6 +-
 sysdeps/x86_64/strlen.S                       |  12 +-
 sysdeps/x86_64/x32/Makefile                   |  11 ++
 sysdeps/x86_64/x32/test-size_t.h              | 170 ++++++++++++++++++
 sysdeps/x86_64/x32/tst-size_t-memchr.c        |  72 ++++++++
 sysdeps/x86_64/x32/tst-size_t-memcmp.c        |  76 ++++++++
 sysdeps/x86_64/x32/tst-size_t-memcpy.c        |  58 ++++++
 sysdeps/x86_64/x32/tst-size_t-memrchr.c       |  57 ++++++
 sysdeps/x86_64/x32/tst-size_t-memset.c        |  73 ++++++++
 sysdeps/x86_64/x32/tst-size_t-strncasecmp.c   |  59 ++++++
 sysdeps/x86_64/x32/tst-size_t-strncmp.c       |  78 ++++++++
 sysdeps/x86_64/x32/tst-size_t-strncpy.c       |  58 ++++++
 sysdeps/x86_64/x32/tst-size_t-strnlen.c       |  72 ++++++++
 sysdeps/x86_64/x32/tst-size_t-wcsncmp.c       |  20 +++
 sysdeps/x86_64/x32/tst-size_t-wcsnlen.c       |  20 +++
 sysdeps/x86_64/x32/tst-size_t-wmemchr.c       |  20 +++
 sysdeps/x86_64/x32/tst-size_t-wmemcmp.c       |  20 +++
 sysdeps/x86_64/x32/tst-size_t-wmemset.c       |  20 +++
 37 files changed, 1034 insertions(+), 96 deletions(-)
 create mode 100644 sysdeps/x86_64/x32/test-size_t.h
 create mode 100644 sysdeps/x86_64/x32/tst-size_t-memchr.c
 create mode 100644 sysdeps/x86_64/x32/tst-size_t-memcmp.c
 create mode 100644 sysdeps/x86_64/x32/tst-size_t-memcpy.c
 create mode 100644 sysdeps/x86_64/x32/tst-size_t-memrchr.c
 create mode 100644 sysdeps/x86_64/x32/tst-size_t-memset.c
 create mode 100644 sysdeps/x86_64/x32/tst-size_t-strncasecmp.c
 create mode 100644 sysdeps/x86_64/x32/tst-size_t-strncmp.c
 create mode 100644 sysdeps/x86_64/x32/tst-size_t-strncpy.c
 create mode 100644 sysdeps/x86_64/x32/tst-size_t-strnlen.c
 create mode 100644 sysdeps/x86_64/x32/tst-size_t-wcsncmp.c
 create mode 100644 sysdeps/x86_64/x32/tst-size_t-wcsnlen.c
 create mode 100644 sysdeps/x86_64/x32/tst-size_t-wmemchr.c
 create mode 100644 sysdeps/x86_64/x32/tst-size_t-wmemcmp.c
 create mode 100644 sysdeps/x86_64/x32/tst-size_t-wmemset.c

-- 
2.20.1

Comments

Florian Weimer Jan. 18, 2019, 10:50 a.m. | #1
* 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
identifier?

Thanks,
Florian
H.J. Lu Jan. 18, 2019, 1:14 p.m. | #2
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?

Thanks.

-- 
H.J.
Florian Weimer Jan. 18, 2019, 1:31 p.m. | #3
* 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.


Yuck.

>> identifier?

>>

>

> Yes, please.  Can you do that for me?


Working on it.

The issue existed since the port was introduced, correct?

Thanks,
Florian
H.J. Lu Jan. 18, 2019, 1:32 p.m. | #4
On Fri, Jan 18, 2019 at 5:31 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.

>

> Yuck.

>

> >> identifier?

> >>

> >

> > Yes, please.  Can you do that for me?

>

> Working on it.

>

> The issue existed since the port was introduced, correct?

>


Yes.

-- 
H.J.
Florian Weimer Jan. 18, 2019, 7:56 p.m. | #5
* 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
add short NEWS entry in the security section.  Thanks.

Florian
H.J. Lu Jan. 18, 2019, 8:15 p.m. | #6
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
  size_t value.  Reported by Florian Weimer.

I will check in the new patch set. tomorrow if there are no objections.


-- 
H.J.
Florian Weimer Jan. 18, 2019, 8:15 p.m. | #7
* Florian Weimer:

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

> add short NEWS entry in the security section.  Thanks.


I should clarify that I have not reviewed the actual patches.

Thanks,
Florian
Florian Weimer Jan. 18, 2019, 8:21 p.m. | #8
* 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
H.J. Lu Jan. 18, 2019, 8:24 p.m. | #9
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
  it happened, the string/memory functions written in assembly would
  cause a buffer overflow if the full 64-bit register was used as the
  32-bit size_t value.  Reported by H.J. Lu.

> >   size_t value.  Reported by Florian Weimer.

>

> Huh.  Did I really report this?  When?


It was my misunderstanding.

-- 
H.J.
Florian Weimer Jan. 18, 2019, 8:40 p.m. | #10
* 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.)

Thanks,
Florian
H.J. Lu Jan. 18, 2019, 8:47 p.m. | #11
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.
Rical Jasan Jan. 19, 2019, 3:23 a.m. | #12
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.

Rical
Florian Weimer Jan. 19, 2019, 10:38 a.m. | #13
* 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.

Thanks,
Florian
H.J. Lu Jan. 19, 2019, 3:13 p.m. | #14
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.

-- 
H.J.
H.J. Lu Jan. 20, 2019, 3:50 p.m. | #15
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.