Date: Sun, 9 Aug 2009 21:55:10 +0200 From: Thomas Backman <serenity@exscape.org> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: FreeBSD current <freebsd-current@freebsd.org> Subject: Re: nmap UDP scan against 8.0-CURRENT -> fatal trap 12 Message-ID: <8934C698-C37D-4DB7-A7F5-4B93014AD0E9@exscape.org> In-Reply-To: <Pine.GSO.4.63.0908091546510.5263@muncher.cs.uoguelph.ca> References: <598778D3-AE7B-47AF-A4F9-0D832BC1A990@exscape.org> <Pine.GSO.4.63.0908091421360.18198@muncher.cs.uoguelph.ca> <00694EF2-9BBC-4733-91C7-A6AE973D8973@exscape.org> <Pine.GSO.4.63.0908091546510.5263@muncher.cs.uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
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 =3D=3D XDR_ENCODE) {
>>> available =3D 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 =20=
>> seconds. Post-patch I've looped the simpler scan for a while (10 =20
>> minutes, or about 8-9 runs) with no crash, and I also ran the more =20=
>> extensive one (which I doubt makes any difference...) once.
>> Just for fun, I tried actually using nfsd while looping the scan, =20
>> too. No problems.
>>
> Ok, sounds good. It's already in the re@ queue, so it should make it =20=
> 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 =20
> 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 =20=
in the crash:
(kgdb) p *xdrs
$2 =3D {x_op =3D XDR_DECODE, x_ops =3D 0xffffffff806a16c0, x_public =3D =20=
0xffffff007ffdc3a8 "=EF=BF=BDZ\t<", x_private =3D 0x0,
x_base =3D 0xffffff000a066e00 "", x_handy =3D 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 =20
particular issue is fixed (for me, anyhow). :)
Regards,
Thomas=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8934C698-C37D-4DB7-A7F5-4B93014AD0E9>