x86-64 memcmp: Use unsigned Jcc instructions on size

Message ID 20190202142723.7730-1-hjl.tools@gmail.com
State Superseded
Headers show
Series
  • x86-64 memcmp: Use unsigned Jcc instructions on size
Related show

Commit Message

H.J. Lu Feb. 2, 2019, 2:27 p.m.
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.

	[BZ #24155]
	* sysdeps/x86_64/memcmp.S: Use RDX_LP for size.  Clear the
	upper 32 bits of RDX register for x32.  Use unsigned Jcc
	instructions, instead of signed.
	* sysdeps/x86_64/x32/Makefile (tests): Add tst-size_t-memcmp-2.
	* sysdeps/x86_64/x32/tst-size_t-memcmp-2.c: New test.
---
 sysdeps/x86_64/memcmp.S                  | 20 +++---
 sysdeps/x86_64/x32/Makefile              |  3 +-
 sysdeps/x86_64/x32/tst-size_t-memcmp-2.c | 79 ++++++++++++++++++++++++
 3 files changed, 93 insertions(+), 9 deletions(-)
 create mode 100644 sysdeps/x86_64/x32/tst-size_t-memcmp-2.c

-- 
2.20.1

Comments

Florian Weimer Feb. 2, 2019, 2:56 p.m. | #1
* 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?

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
security vulnerability, we need a new CVE ID because the version range
is different (bug 24155 was not fixed in the 2.29 release).

Thanks,
Florian
H.J. Lu Feb. 2, 2019, 3:02 p.m. | #2
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.

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

Thanks.

-- 
H.J.
Florian Weimer Feb. 2, 2019, 3:32 p.m. | #3
* 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
H.J. Lu Feb. 2, 2019, 3:39 p.m. | #4
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.
Florian Weimer Feb. 3, 2019, 8:33 a.m. | #5
* H. J. Lu:

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


MITRE has assigned CVE-2019-7309.  Please mention it in the appropriate
places.

Thanks,
Florian

Patch

diff --git a/sysdeps/x86_64/memcmp.S b/sysdeps/x86_64/memcmp.S
index 1fc487caa5..1322bb3b92 100644
--- a/sysdeps/x86_64/memcmp.S
+++ b/sysdeps/x86_64/memcmp.S
@@ -21,14 +21,18 @@ 
 
 	.text
 ENTRY (memcmp)
-	test	%rdx, %rdx
+#ifdef __ILP32__
+	/* Clear the upper 32 bits.  */
+	movl	%edx, %edx
+#endif
+	test	%RDX_LP, %RDX_LP
 	jz	L(finz)
 	cmpq	$1, %rdx
-	jle	L(finr1b)
+	jbe	L(finr1b)
 	subq	%rdi, %rsi
 	movq	%rdx, %r10
 	cmpq	$32, %r10
-	jge	L(gt32)
+	jae	L(gt32)
 	/* Handle small chunks and last block of less than 32 bytes.  */
 L(small):
 	testq	$1, %r10
@@ -156,7 +160,7 @@  L(A32):
 	movq	%r11, %r10
 	andq	$-32, %r10
 	cmpq	%r10, %rdi
-        jge	L(mt16)
+        jae	L(mt16)
 	/* Pre-unroll to be ready for unrolled 64B loop.  */
 	testq	$32, %rdi
 	jz	L(A64)
@@ -178,7 +182,7 @@  L(A64):
 	movq	%r11, %r10
 	andq	$-64, %r10
 	cmpq	%r10, %rdi
-        jge	L(mt32)
+        jae	L(mt32)
 
 L(A64main):
 	movdqu    (%rdi,%rsi), %xmm0
@@ -216,7 +220,7 @@  L(mt32):
 	movq	%r11, %r10
 	andq	$-32, %r10
 	cmpq	%r10, %rdi
-        jge	L(mt16)
+        jae	L(mt16)
 
 L(A32main):
 	movdqu    (%rdi,%rsi), %xmm0
@@ -254,7 +258,7 @@  L(ATR):
 	movq	%r11, %r10
 	andq	$-32, %r10
 	cmpq	%r10, %rdi
-        jge	L(mt16)
+        jae	L(mt16)
 	testq	$16, %rdi
 	jz	L(ATR32)
 
@@ -325,7 +329,7 @@  L(ATR64main):
 	movq	%r11, %r10
 	andq	$-32, %r10
 	cmpq	%r10, %rdi
-        jge	L(mt16)
+        jae	L(mt16)
 
 L(ATR32res):
 	movdqa    (%rdi,%rsi), %xmm0
diff --git a/sysdeps/x86_64/x32/Makefile b/sysdeps/x86_64/x32/Makefile
index 1557724b0c..8748956563 100644
--- a/sysdeps/x86_64/x32/Makefile
+++ b/sysdeps/x86_64/x32/Makefile
@@ -8,7 +8,8 @@  endif
 ifeq ($(subdir),string)
 tests += tst-size_t-memchr tst-size_t-memcmp tst-size_t-memcpy \
 	 tst-size_t-memrchr tst-size_t-memset tst-size_t-strncasecmp \
-	 tst-size_t-strncmp tst-size_t-strncpy tst-size_t-strnlen
+	 tst-size_t-strncmp tst-size_t-strncpy tst-size_t-strnlen \
+	 tst-size_t-memcmp-2
 endif
 
 ifeq ($(subdir),wcsmbs)
diff --git a/sysdeps/x86_64/x32/tst-size_t-memcmp-2.c b/sysdeps/x86_64/x32/tst-size_t-memcmp-2.c
new file mode 100644
index 0000000000..d8ae1a0813
--- /dev/null
+++ b/sysdeps/x86_64/x32/tst-size_t-memcmp-2.c
@@ -0,0 +1,79 @@ 
+/* Test memcmp with size_t in the lower 32 bits of 64-bit register.
+   Copyright (C) 2019 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   The GNU C Library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with the GNU C Library; if not, see
+   <http://www.gnu.org/licenses/>.  */
+
+#define TEST_MAIN
+#ifdef WIDE
+# define TEST_NAME "wmemcmp"
+#else
+# define TEST_NAME "memcmp"
+#endif
+
+#include "test-size_t.h"
+
+#ifdef WIDE
+# include <inttypes.h>
+# include <wchar.h>
+
+# define MEMCMP wmemcmp
+# define CHAR wchar_t
+#else
+# define MEMCMP memcmp
+# define CHAR char
+#endif
+
+IMPL (MEMCMP, 1)
+
+typedef int (*proto_t) (const CHAR *, const CHAR *, size_t);
+
+static int
+__attribute__ ((noinline, noclone))
+do_memcmp (parameter_t a, parameter_t b)
+{
+  return CALL (&b, a.p, b.p, a.len);
+}
+
+static int
+test_main (void)
+{
+  test_init ();
+
+  parameter_t dest = { { page_size / sizeof (CHAR) }, buf1 };
+  parameter_t src = { { 0 }, buf2 };
+
+  memcpy (buf1, buf2, page_size);
+
+  CHAR *p = (CHAR *) buf1;
+  p[page_size / sizeof (CHAR) - 1] = (CHAR) 1;
+
+  int ret = 0;
+  FOR_EACH_IMPL (impl, 0)
+    {
+      src.fn = impl->fn;
+      int res = do_memcmp (dest, src);
+      if (res >= 0)
+	{
+	  error (0, 0, "Wrong result in function %s: %i >= 0",
+		 impl->name, res);
+	  ret = 1;
+	}
+    }
+
+  return ret ? EXIT_FAILURE : EXIT_SUCCESS;
+}
+
+#include <support/test-driver.c>