[llvm-bugs] [Bug 43633] New: AddressSanitizer doesn't catch stack-use-after-return of variable-length arrays

via llvm-bugs llvm-bugs at lists.llvm.org
Thu Oct 10 01:12:11 PDT 2019


https://bugs.llvm.org/show_bug.cgi?id=43633

            Bug ID: 43633
           Summary: AddressSanitizer doesn't catch stack-use-after-return
                    of variable-length arrays
           Product: compiler-rt
           Version: 8.0
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: asan
          Assignee: unassignedbugs at nondot.org
          Reporter: csander at caltech.edu
                CC: llvm-bugs at lists.llvm.org

ASAN correctly warns when dereferencing a returned reference to a local
fixed-length array. See this example:

```
#include <stdio.h>

int *returns_dangling_pointer() {
  int a[5];
  for (size_t i = 0; i < 5; i++) a[i] = i;
  return &a[3];
}

int main() {
  printf("%d\n", *returns_dangling_pointer());
}
```

Compiling with clang -fsanitize=address and running the program with
ASAN_OPTIONS=detect_stack_use_after_return=1 reports a stack use after return,
as expected:
[32, 52) 'a' <== Memory access at offset 44 is inside this variable

But if the array is replaced by a VLA, ASAN does not catch the undefined
behavior. Example:

```
#include <stdio.h>

int *returns_dangling_pointer(size_t len) {
  int a[len];
  for (size_t i = 0; i < 5; i++) a[i] = i;
  return &a[3];
}

int main() {
  printf("%d\n", *returns_dangling_pointer(5));
}
```

Compiling and running as before, the program prints 3 and exits normally. I
would have expected ASAN to identify that the returned pointer refers to
stack-allocated memory that is no longer valid once returns_dangling_pointer()
returns.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20191010/d8edd250/attachment.html>


More information about the llvm-bugs mailing list