IssueTracker

LLVM's SafeStack sanitizer (enabled with clang option -fsanitizer=safe-stack) incorrectly and unsafely instruments the llvm.stacksave intrinsic (which returns the current value of the stack pointer, rsp on x86-64) by replacing all calls to that intrinsic with a load of SafeStack's unsafe stack pointer (llvm/lib/CodeGen/SafeStack.cpp:711). This works most of the time, since (1) all dynamic allocations are moved to the unsafe stack and (2) the value returned by llvm.stacksave is generally only ever passed to llvm.stackrestore to implement scoped VLAs. However, one less common use case of llvm.stacksave is to save the current value of the stack pointer in a setjmp buffer. Subsequent longjmp's expect the native stack pointer in the setjmp buffer; however, SafeStack's instrumentation causes the unsafe stack pointer to be stored in the setjmp buffer instead. When a longjmp is executed, this results in the _unsafe_ stack pointer to be loaded into the _native_ stack pointer rsp, effectively switching callstacks from the native safe stack to SafeStack's unsafe stack, which likely contains attacker-controlled data. Thus, an attacker can launch a ROP attack following such a vulnerable longjmp.

Attached is a proof of concept (poc.c) and a malicious input file passed to the miscompiled program. Compile it as follows:
```
clang -fsanitize=safe-stack poc.c
```
This produces an executable `a.out`. Run it under valgrind, redirecting input from in.txt (attached), to observe a return to 0xdeadbeef:
```
valgrind ./a.out < in.txt
```