Date: Mon, 8 Jan 2018 16:13:42 +0100 From: Ed Schouten <ed@nuxi.nl> To: Andrew Turner <andrew@fubar.geek.nz> Cc: Ed Schouten <ed@freebsd.org>, src-committers <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: <CABh_MKm4HW2nJ=402oiELgWDo=Q7h15kjOU1p6F2BPOchjZCiw@mail.gmail.com> 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 Andrew, 2018-01-08 8:37 GMT+01:00 Andrew Turner <andrew@fubar.geek.nz>: > Won=E2=80=99t this lead to a NULL pointer dereference on overflow? malloc= array 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. --=20 Ed Schouten <ed@nuxi.nl> Nuxi, 's-Hertogenbosch, the Netherlands
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CABh_MKm4HW2nJ=402oiELgWDo=Q7h15kjOU1p6F2BPOchjZCiw>