ojhunt wrote:

> These changes in semantics can introduce security vulnerabilities where 
> previously none existed. Take the format string example in the RFC, which was 
> called out as a result of this change in behavior, which is the reason I 
> assumed it had be removed:

Sorry, I didn't include the most obvious security vulnerability:

```cpp
   uint16_t __wrap count = ...;
   malloc(sizeof(SomeType) * count);
```

The narrowing behavior truncates the allocation size.

Just to be clear though, the developer may not have explicitly state `__wrap` 
here: because of the way types are merged and propagated that `uint16_t __wrap` 
may have originally been a uint64_t, but every operation involving the 
`uint16_t __wrap` has resulted in the types being constantly narrowed. That 
would mean even if the code was

```cpp
   uint64_t count = ...;
   malloc(sizeof(SomeType) * count);
```

The RHS expression may have already been truncated - it might directly have the 
type `uint16_t __wrap` or that may have been lost earlier on, making it even 
harder to track down.



https://github.com/llvm/llvm-project/pull/148914
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Reply via email to