[llvm-bugs] [Bug 35163] New: UBSan -fsanitize=alignment doesn't warn about memcpy unalignment
via llvm-bugs
llvm-bugs at lists.llvm.org
Wed Nov 1 13:50:30 PDT 2017
https://bugs.llvm.org/show_bug.cgi?id=35163
Bug ID: 35163
Summary: UBSan -fsanitize=alignment doesn't warn about memcpy
unalignment
Product: new-bugs
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedbugs at nondot.org
Reporter: kcc at google.com
CC: llvm-bugs at lists.llvm.org
>From https://github.com/google/sanitizers/issues/876
-fsanitize=alignment does a great job at spotting misaligned reads when
dereferencing pointers, but doesn't realize about them if they are passed to
memcpy.
You might say "wait, but memcpy doesn't require any alignment guarantee".
Well the problem is that if you trick the compiler into thinking that the
argument is aligned, it will emit very efficient code for memcpy that will
assume alignment, and later crash on architectures that don't support unaligned
reads (e.g. ARM).
I witnessed this sort of bug twice this year
https://bugs.chromium.org/p/chromium/issues/detail?id=729059#c4
grpc/grpc#13221
Today, after 2, I wondered: isn't UBsan supposed to spot this?
Unfortunately it seems that it doesn't. Here's the minified repro:
Build with
clang++ -o test test.cc -std=c++11 -O3 -fsanitize=undefined
-fsanitize=alignment
#include <stdint.h>
#include <stdio.h>
#include <string.h>
int main() {
char x[128] = {};
uint32_t* p = reinterpret_cast<uint32_t*>(&x[1]);
uint32_t v = 42;
// This is UB, p is a uint32_t pointer and the compiler is
// allowed to assume it's aligned (in fact it will SIGBUS on arm)
// but UBSan doesn't complain about this.
memcpy(p, &v, sizeof(uint32_t));
// Instead UBSan would complain about this, which is also UB.
v = *p;
printf("%x %x %x %x\n", x[1], x[2], x[3], x[4]);
}
<the reporter doesn't have access to the LLVM bug tracker, and subscriptions
are closed for spam>
--
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/20171101/0364383e/attachment.html>
More information about the llvm-bugs
mailing list