[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