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
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
