Date: Mon, 8 Jan 2018 10:08:47 -0500 From: Pedro Giffuni <pfg@FreeBSD.org> To: Andrew Turner <andrew@fubar.geek.nz>, Ed Schouten <ed@FreeBSD.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r327684 - in head/sys/compat: cloudabi32 cloudabi64 Message-ID: <191085f4-3496-e063-474f-3193a3188275@FreeBSD.org> In-Reply-To: <8D8CA434-2A87-44D9-AC27-5166802FBBC2@fubar.geek.nz> References: <201801072238.w07McjLP099234@repo.freebsd.org> <8D8CA434-2A87-44D9-AC27-5166802FBBC2@fubar.geek.nz>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi; On 08/01/2018 02:37, Andrew Turner wrote: >> On 7 Jan 2018, at 22:38, Ed Schouten <ed@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?191085f4-3496-e063-474f-3193a3188275>