On Monday, 3 January 2022 at 00:52:38 UTC, Brian Callahan wrote:
> Perhaps D should provide a similar function

int[] array;

array.length = 5;

On Monday, 3 January 2022 at 00:52:38 UTC, Brian Callahan wrote:
> Perhaps D should provide a similar function

What is wrong with Mallocator, mentioned else-thread?

On Friday, 31 December 2021 at 13:52:26 UTC, Paul Backus wrote:
> On Friday, 31 December 2021 at 00:13:56 UTC, Walter Bright wrote:
>> While D offers buffer overflow detection, it does not protect against buffer overflows resulting from an array size calculation overflow:
>>
>>     T* p = cast(T*)malloc(len * T.sizeof);
>>
>> What if `len*T.sizeof` overflows? malloc() will succeed, but the result will be too small for the data.
>
> For projects using Phobos, an easy way to avoid this is to use [`Mallocator`][1] and [`makeArray`][2] from the `std.experimental.allocator` package.
>
>     T[] array = Mallocator.instance.makeArray!T(len);
>
> `makeArray` will perform an overflow check internally and return `null` if the check fails.
>
> [1]: https://dlang.org/library/std/experimental/allocator/mallocator/mallocator.html
> [2]: https://dlang.org/library/std/experimental/allocator/make_array.html

In the vulnerability described in the article, the 'len' parameter is the result of a sum overflowing in a previous for loop, so the problem actually is _outside_ of the allocator.

Anyway, apart from the vulnerability, the described exploit details are fascinating and terrific at the same time ..."My other compression format is turing-complete!"

On Monday, 3 January 2022 at 12:58:33 UTC, Paolo Invernizzi wrote:
>
> In the vulnerability described in the article, the 'len' parameter is the result of a sum overflowing in a previous for loop, so the problem actually is _outside_ of the allocator.
>

That is not entirely correct, and could mislead one into implementing a less than optimal solution to the problem.

The overflow and the allocater 'together', provide the attack surface.

On Monday, 3 January 2022 at 21:00:38 UTC, forkit wrote:
> On Monday, 3 January 2022 at 12:58:33 UTC, Paolo Invernizzi wrote:
>>
>> In the vulnerability described in the article, the 'len' parameter is the result of a sum overflowing in a previous for loop, so the problem actually is _outside_ of the allocator.
>>
>
> That is not entirely correct, and could mislead one into implementing a less than optimal solution to the problem.
>
> The overflow and the allocater 'together', provide the attack surface.

I agree that the _surface_ is the couple, but the vulnerability to patch is how the needed amount is calculated, and that can be an arbitrary complex piece of code. A super-duper-safe allocator does not help here, if we are talking about a system language and write to memory via pointers arithmetic.