From owner-svn-src-all@FreeBSD.ORG Wed Aug 17 20:03:11 2011 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5CFA106566C; Wed, 17 Aug 2011 20:03:11 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C42558FC13; Wed, 17 Aug 2011 20:03:11 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 517AE46B2E; Wed, 17 Aug 2011 16:03:11 -0400 (EDT) Date: Wed, 17 Aug 2011 21:03:11 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Poul-Henning Kamp In-Reply-To: <201105171104.p4HB4oD0028308@svn.freebsd.org> Message-ID: References: <201105171104.p4HB4oD0028308@svn.freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r222015 - head/sys/kern X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 20:03:12 -0000 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