[llvm-bugs] [Bug 43478] New: -fstack-protector-strong doesn't catch direct out-of-bounds via non-array

via llvm-bugs llvm-bugs at lists.llvm.org
Fri Sep 27 05:03:37 PDT 2019


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

            Bug ID: 43478
           Summary: -fstack-protector-strong doesn't catch direct
                    out-of-bounds via non-array
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Common Code Generator Code
          Assignee: unassignedbugs at nondot.org
          Reporter: john.brawn at arm.com
                CC: llvm-bugs at lists.llvm.org

If the following is compiled with -O0 -fstack-protector-strong

  int n = 4;
  int fn() {
    long x = 0;
    (&x)[n] = 1; // out-of-bounds write
    return x;
  }

then we generate an out-of-bounds write to the stack, but don't insert stack
protector code (with -O1 the write is optimised to a write to x under the
assumption that n must be 0, so there's no out-of-bounds write).

What's going on here is that for -fstack-protector-strong we insert the stack
protection if StackProtector::HasAddressTaken sees that the address of x is
stored somewhere (or rather we will once PR43308 is done, currently it's
PointerMayBeCaptured doing this check). If the address is directly used in a
gep which is used as the address operand of a store then this isn't detected.

As to what to do about this, counting all uses of the address in a store as
requiring stack protection is too much as that would catch all simple stores
(i.e. x = n). Probably instead we want to catch the case when the address is
used in a gep that possibly is out-of-bounds, and that gep value is then the
address operand of a store (or something store-like such as cmpxchg).

-- 
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/20190927/384ac092/attachment.html>


More information about the llvm-bugs mailing list