[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