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

[Pedro Giffuni]

Hi;

On 08/01/2018 02:37, Andrew Turner wrote:
>> On 7 Jan 2018, at 22:38, Ed Schouten <ed at FreeBSD.org> wrote:
>>
>> Author: ed
>> Date: Sun Jan  7 22:38:45 2018
>> New Revision: 327684
>> URL: https://svnweb.freebsd.org/changeset/base/327684
>>
>> Log:
>>   Use mallocarray(9) in CloudABI kernel code where possible.
>>
>>   Submitted by:	pfg@
>>
>> Modified:
>>   head/sys/compat/cloudabi32/cloudabi32_sock.c
>>   head/sys/compat/cloudabi64/cloudabi64_sock.c
>>
>> Modified: head/sys/compat/cloudabi32/cloudabi32_sock.c
>> ==============================================================================
>> --- head/sys/compat/cloudabi32/cloudabi32_sock.c	Sun Jan  7 22:21:07 2018	(r327683)
>> +++ head/sys/compat/cloudabi32/cloudabi32_sock.c	Sun Jan  7 22:38:45 2018	(r327684)
>> @@ -60,7 +60,7 @@ cloudabi32_sys_sock_recv(struct thread *td,
>> 	/* Convert iovecs to native format. */
>> 	if (ri.ri_data_len > UIO_MAXIOV)
>> 		return (EINVAL);
>> -	iov = malloc(ri.ri_data_len * sizeof(struct iovec),
>> +	iov = mallocarray(ri.ri_data_len, sizeof(struct iovec),
>> 	    M_SOCKET, M_WAITOK);
> Won’t this lead to a NULL pointer dereference on overflow? mallocarray can return NULL even with M_WAITOK.
I think you are right: for the M_WAITOK case we should do the check 
outside the malloc.

Compilers and static checkers should be giving out a warning since 
mallocarray() has the __result_use_check attribute (is that working!?). 
In the case of malloc(9) we should remove the attribute since we can by 
using M_WAITOK.

And yes, this patch should be reverted.

Pedro.