When compiled as mempcpy, the return value is the end of the destination
buffer, thus it cannot be used to refer to the start of it.
(cherry picked from commit
9aaaab7c6e4176e61c59b0a63c6ba906d875dc0e)
+2018-05-23 Andreas Schwab <schwab@suse.de>
+
+ [BZ #23196]
+ CVE-2018-11237
+ * sysdeps/x86_64/multiarch/memmove-avx512-no-vzeroupper.S
+ (L(preloop_large)): Save initial destination pointer in %r11 and
+ use it instead of %rax after the loop.
+ * string/test-mempcpy.c (MIN_PAGE_SIZE): Define.
+
2018-05-11 Florian Weimer <fweimer@redhat.com>
[BZ #23166]
build with -Os)
[23152] gd_GB: Fix typo in "May" (abbreviated)
[23166] sunrpc: Remove stray exports without --enable-obsolete-rpc
+ [23196] __mempcpy_avx512_no_vzeroupper mishandles large copies
+
+Security related changes:
+
+ CVE-2018-11237: The mempcpy implementation for the Intel Xeon Phi
+ architecture could write beyond the target buffer, resulting in a buffer
+ overflow. Reported by Andreas Schwab.
\f
Version 2.27
<http://www.gnu.org/licenses/>. */
#define MEMCPY_RESULT(dst, len) (dst) + (len)
+#define MIN_PAGE_SIZE 131072
#define TEST_MAIN
#define TEST_NAME "mempcpy"
#include "test-string.h"
vmovups (%rsi), %zmm4
vmovups 0x40(%rsi), %zmm5
+ mov %rdi, %r11
/* Align destination for access with non-temporal stores in the loop. */
mov %rdi, %r8
and $-0x80, %rdi
cmp $256, %rdx
ja L(gobble_256bytes_nt_loop)
sfence
- vmovups %zmm4, (%rax)
- vmovups %zmm5, 0x40(%rax)
+ vmovups %zmm4, (%r11)
+ vmovups %zmm5, 0x40(%r11)
jmp L(check)
L(preloop_large_bkw):