NagyDonat wrote:
> I think the error node needs to be non-fatal.
Good point, I completely agree.
> For these applications it's more important to catch cases where malloc size
> and index used for access are coming from "different sources", eg. one is
> tainted and another isn't, doesn't matter which one.
I agree that we should enable the "pessimistic" handling (= report an error if
we can't prove that the index is in bounds) for cases when the size is tainted,
and I'm planning to create a commit that does this in `ArrayBoundCheckerV2`.
(Previously passing a tainted value to `malloc` was an error, so this case
simply never appeared.)
I would not emphasize "_different_ sources" in this context: a tainted index
deserves careful handling even if the offset is also tainted. I see that this
could produce false positives in situations like
```
char *f() {
size_t n = get_tainted_value();
if (!n)
return NULL; // Rule out the case when n - 1 overflows.
char *p = (char*)malloc(n);
p[n-1] = '\0';
return p;
}
```
where (AFAIK) the analyzer cannot conclude that `n - 1 < n` always holds under
the known constraints. However, I think this wouldn't be very common, and if it
turns out to be common, then we could improve the evaluation of the comparison
operators by handling the case of `symbol + constant <=> same symbol`.
https://github.com/llvm/llvm-project/pull/92420
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
