https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
Bug ID: 110027
Summary: Misaligned vector store on
detect_stack_use_after_return
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: sneves at dei dot uc.pt
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
(As reported by Jack O'Connor, along with reproducibility instructions, at
https://gist.github.com/oconnor663/69176654f1db1bb96077d6ff4141a022)
Given the following snippet,
#include <immintrin.h>
int main() {
__m512i v = _mm512_set1_epi32(0);
// It doesn't really matter what we do next, as long as we convince the
// compiler to put v on the stack. Here we just read an int from it.
return *((int *)&v);
}
compiled with `gcc repro.c -g -mavx512f -fsanitize=address` results in a
segfault due to a misaligned AVX-512 store. The assembly output is visible at
https://gist.github.com/oconnor663/69176654f1db1bb96077d6ff4141a022#file-repro-s.
Specifically, we have the relevant sequence
andq $-64, %rsp
subq $192, %rsp
leaq 32(%rsp), %rbx
...
cmpl $0, __asan_option_detect_stack_use_after_return(%rip)
je .L1
...
call __asan_stack_malloc_1@PLT
...
movq %rax, %rbx
...
.L1:
leaq 160(%rbx), %rax
movq %rax, %rcx
...
vmovdqa64 %zmm0, -128(%rcx)
Now, if `__asan_option_detect_stack_use_after_return` is 0, the variable at
%rcx-128 is correctly aligned to 64. However, if it is 1, __asan_stack_malloc_1
returns something aligned to 64 << 1 (as per
https://github.com/gcc-mirror/gcc/blob/master/gcc/asan.cc#L1917) and adding 160
results in %rcx-128 being only aligned to 32. And thus the segfault.
Interestingly this seems to be only reproducible on Arch Linux. Other gcc
13.1.1 builds, Fedora for instance, seem to behave correctly. It is unclear to
me what the reason for this is.
