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>