svn commit: r327684 - in head/sys/compat: cloudabi32 cloudabi64

[Warner Losh]

On Jan 8, 2018 8:37 AM, "Pedro Giffuni" <pfg at freebsd.org> wrote:


On 01/08/18 10:13, Ed Schouten wrote:

> Hi Andrew,
>
> 2018-01-08 8:37 GMT+01:00 Andrew Turner <andrew at fubar.geek.nz>:
>
>> Won’t this lead to a NULL pointer dereference on overflow? mallocarray
>> can return NULL even with M_WAITOK.
>>
> Yes, it will, but an overflow shouldn't happen in the first place.
> ri_data_len is compared with UIO_MAXIOV a few lines above. Even if an
> overflow would happen, this would cause a kernel panic due to a NULL
> pointer dereference later on, which is likely easier to debug than
> some piece of code that overruns a buffer.
>
> In this case, mallocarray() is preferred, because it makes it more
> obvious that we're allocating a buffer that is accessed as an array,
> as opposed to single structure.
>
> OK...

The behavior of mallocarray() somewhat inconsistent with malloc(9),
realloc(9) and reallocf(9) but this is clearly documented., so we just
assume the developer knows what he/she is doing :).


This is one reason it didn't go in before... the error semantics suck... we
re are a poor match for existing code.

Warner