[clang] [analyzer] Moving TaintPropagation checker out of alpha (PR #67352)
Artem Dergachev via cfe-commits
cfe-commits at lists.llvm.org
Tue Sep 26 13:37:54 PDT 2023
haoNoQ wrote:
> @haoNoQ I don't really understand your remark that
>
> > The report may be technically correct but I think the entire idea of the checker never made sense in the first place. It doesn't matter that untrusted data is used to specify buffer size once; it matters that data with _different levels of trust_, or _coming from different sources_, is used to specify size of the _same buffer on different occasions_.
>
> What does "size of the same buffer on different occasions" mean here? I'd guess that it refers to something like
>
> ```c++
> void *get_mem(bool use_default_size) {
> size_t size = 1024;
> if (!use_default_size)
> size = get_tainted_number_from_config_file();
> // do something important that we want to do before each allocation...
> return malloc(size);
> }
> ```
>
> but I'd argue that this is actually valid (although a bit unusual) code.
No-no, I mean whatever I said in the next sentence, like literally the same buffer, not the same allocation site, not the same variable, but literally the same allocation, except it has multiple size-aware operations performed on it, like this:
```c
size_t N = tainted();
size_t M = 10;
// Should warn. Out-of-bounds access if N is too large.
char *buf1 = malloc(M);
memset(buf1, 0, N);
// Should warn. Out-of-bounds access if N is too small.
char *buf2 = malloc(N);
memset(buf2, 0, M);
// Perfectly valid code, even if both accesses are performed with tainted, unconstrained size.
char *buf3 = malloc(N);
memset(buf3, 0, N);
```
https://github.com/llvm/llvm-project/pull/67352
More information about the cfe-commits
mailing list