Date: Wed, 17 Aug 2011 21:03:11 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Poul-Henning Kamp <phk@FreeBSD.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r222015 - head/sys/kern Message-ID: <alpine.BSF.2.00.1108172100100.66376@fledge.watson.org> In-Reply-To: <201105171104.p4HB4oD0028308@svn.freebsd.org> References: <201105171104.p4HB4oD0028308@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 17 May 2011, Poul-Henning Kamp wrote:
> + if ((s->s_flags & SBUF_AUTOEXTEND) == 0) {
> + KASSERT(s->s_size > 1,
> + ("attempt to create a too small sbuf"));
> + }
This change turns out to cause a kernel panic during fuzzing of
mac_proc_get(2). Previously the code checked for a non-negative userspace
buffer size, and also a bound at a max buffer length. While '0' is a bit of a
silly buffer size to pass in, so is '1' (enough room for just a nul), and '2'
(can't fit a useful string there), etc, so it's not extremely silly. I'd
rather we had left this assertion as-is as it didn't relate to the actual
functional change here. Can I convince you to revert that, rather than us
having to walk through the kernel to try to find this and other instances of
possibly passing a zero-size buffer in? (On a related note, zero-size buffers
are accepted by most string routines...)
Robert
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1108172100100.66376>