nmap UDP scan against 8.0-CURRENT -> fatal trap 12

[Thomas Backman]

On Aug 9, 2009, at 21:53, Rick Macklem wrote:
> On Sun, 9 Aug 2009, Thomas Backman wrote:
>
> [stuff snipped]
>>> --- xdr/xdr_mbuf.c.sav	2009-08-07 15:02:35.000000000 -0400
>>> +++ xdr/xdr_mbuf.c	2009-08-07 15:03:04.000000000 -0400
>>> @@ -282,6 +282,8 @@
>>> 	size_t available;
>>> 	char *p;
>>> +	if (!m)
>>> +		return (0);
>>> 	if (xdrs->x_op == XDR_ENCODE) {
>>> 		available = M_TRAILINGSPACE(m) + (m->m_len - xdrs->x_handy);
>>> 	} else {
>>
>> Initial results are certainly good! :-)
>> Pre-patch, it panicked three times in a row, as I said within a few  
>> seconds. Post-patch I've looped the simpler scan for a while (10  
>> minutes, or about 8-9 runs) with no crash, and I also ran the more  
>> extensive one (which I doubt makes any difference...) once.
>> Just for fun, I tried actually using nfsd while looping the scan,  
>> too. No problems.
>>
> Ok, sounds good. It's already in the re@ queue, so it should make it  
> into
> 8.0. If it does crap out again, please let the list (and me) know.
>
> Thanks for testing the patch, rick
> ps: Thanks mostly goes to pho@ for his "wicked" test scripts that  
> found
>    the crash that the above patch fixes + a bunch of others.
I just looked at the xdrs variable in kgdb, and "m" would indeed be 0  
in the crash:
(kgdb) p *xdrs
$2 = {x_op = XDR_DECODE, x_ops = 0xffffffff806a16c0, x_public =  
0xffffff007ffdc3a8 "�Z\t<", x_private = 0x0,
   x_base = 0xffffff000a066e00 "", x_handy = 0}
And since m is "xdrs->x_private", accessing m wouln't be a good idea.
As a newbie, I still think it's safe to say that at least this  
particular issue is fixed (for me, anyhow). :)

Regards,
Thomas