From owner-svn-src-head@FreeBSD.ORG  Wed Aug 17 20:03:11 2011
Return-Path: <owner-svn-src-head@FreeBSD.ORG>
Delivered-To: svn-src-head@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 <rwatson@FreeBSD.org>
X-X-Sender: robert@fledge.watson.org
To: Poul-Henning Kamp <phk@FreeBSD.org>
In-Reply-To: <201105171104.p4HB4oD0028308@svn.freebsd.org>
Message-ID: <alpine.BSF.2.00.1108172100100.66376@fledge.watson.org>
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-head@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SVN commit messages for the src tree for head/-current
	<svn-src-head.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/svn-src-head>,
	<mailto:svn-src-head-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/svn-src-head>
List-Post: <mailto:svn-src-head@freebsd.org>
List-Help: <mailto:svn-src-head-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/svn-src-head>,
	<mailto:svn-src-head-request@freebsd.org?subject=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