================
@@ -15,8 +15,8 @@ int TenElements[10];
int irrelevantAssumptions(int arg) {
int a = TenElements[arg];
- // Here the analyzer assumes that `arg` is in bounds, but doesn't report this
- // because `arg` is not interesting for the bug.
+ // expected-warning@-1 {{Out of bound access to memory around 'TenElements'}}
+ // expected-note@-2 {{Access of 'TenElements' at a negative or overflowing
index, while it holds only 10 'int' elements}}
----------------
haoNoQ wrote:
I think this was working as intended. This checker isn't trying to force the
user to check the bounds before every array access. Normally it's only telling
the user that the OOB access *definitely* happens. Otherwise, even if the value
isn't sufficiently constrained, this doesn't mean that it can actually take all
the values it's constrained to. There may be implicit constraints that we
aren't aware of.
And then there's the tainted case where we confirm that the value isn't merely
unknown, it's actually read from an untrusted source. Like, when we've observed
a literal read operation from user input or from network. In this case we're
certain that there can be no implicit constraints. The constraints we've
recorded so far are all we have. The value can truly be any value within those
constraints. Then that's definitely a true positive.
So in this case we can't tell whether this was a false negative or a true
negative. The checker is designed to stay silent here.
So if you're looking to catch this case, the right solution is to probably
acknowledge the taint source. Eg., you may be interested in an "aggressive"
mode that treats all function parameters as taint sources. Or, indeed, treat
all unknown values as if they're tainted, which effectively means turning off
the taint logic entirely like you did in your patch. But we gotta ask the user
to explicitly opt in into such an aggressive mode because most of the
in-the-wild users don't usually like this sort of stuff. For them the checker
is working as intended.
https://github.com/llvm/llvm-project/pull/161723
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits