[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