Bug 30112

	Rebooting to multi-user mode or viewing machdep.msgbuf would
	consistently panic the machine in slow_copyout() (part of i586
	generic_copyout()).  The crash dump showed that msgbufp->msg_bufr
	contained garbage (though the other fields appeared sane).

	The code in msgbufinit() will reuse an existing message buffer
	(preserving the contents across crashes where possible) but only
	checks the magic number and buffer pointer for validity.  The
	read index, write index and size are not validated if the buffer
	is reused.  This means that should these fields become corrupt,
 	the kernel can access random memory when reading or writing the
	message buffer.

	Whilst it is possible to wipe a corrupted message buffer with
	the sysctl kern.msgbuf_clear, the kernel should better validate
	structures that it is trusting.

Fix: The following patch better validates an existing msgbufp, but
	does not further check it.  It may be reasonable to add some
	KASSERT()s in (eg) msgaddchar(), but it would be necessary to
	ensure that triggering the KASSERT() would not lead to nested
	panic()s [msgbufp is corrupt, triggering a panic(), which logs
	the panic via msgaddchar() which detects that msgbufp is
	corrupt and panics()].

	Note that whilst this patch is running, I had manually cleared
	the corruption before rebooting, so it has not been tested on
	a corrupt msgbufp.
How-To-Repeat: 	(This is a possible scenario - I haven't actually tried this).
	Using a debugger, set msgbufp->msg_bufr to a nonsense value
	and the read the message buffer.  The system will panic and
	upon rebooting will again panic when syslogd starts.