[LLVMbugs] [Bug 24069] New: When both asan and ubsan are enabled, use asan to detect address validity for ubsan checks

[bugzilla-daemon at llvm.org]

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

            Bug ID: 24069
           Summary: When both asan and ubsan are enabled, use asan to
                    detect address validity for ubsan checks
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: richard-llvm at metafoo.co.uk
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Similar to PR19811: when asan and ubsan are both enabled, and ubsan emits a
type-check for some pointer, it should also query asan's shadow map to
determine whether the pointer points to addressable storage.

More specifically, in CodeGenFunction::EmitTypeCheck, around where we emit a
call to the llvm.objectsize intrinsic, we should emit something else that the
asan instrumentation can lower into a size check.

One possibility: replace the call to llvm.objectsize with a call to a new "i1
@llvm.objectsize.atleast.i64(i8* %0, i64 %1)" that determines whether %0 is
known to point to an object of size at least %1 bytes (returning i1 true if
unknown); asan can lower that to a shadow map check, and llvm can otherwise
lower it to @llvm.objectsize plus a comparison.


Some sample cases that we should be able to catch with this change:

 * Reference-binding, member access, pointer cast after free:

  struct S { void f() {} int n; }; struct T : S {};
  S *p = new S;
  delete p;
  S &r = *p;      // #1
  int *k = &p->n; // #2
  p->f();         // #3
  T *q = (T*)p;   // #4

  (and so on, for each case that the ubsan objectsize / null sanitizers catch
today).

 * Bad downcasts where the target type is too large:

  struct A { int n; };
  struct B : A { int m; };
  A *f() { return new A; } // assume not inlined
  B *p = (B*)f(); // catch this because we can't address 8 bytes from f().

 * Placement new on insufficient storage:

  char arr[8];
  struct A { int x, y, z; A() {} };
  new (arr) A;

-- 
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/20150708/f113512d/attachment.html>