From owner-freebsd-current@FreeBSD.ORG Sun Aug 9 19:55:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C50E106564A for ; Sun, 9 Aug 2009 19:55:18 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id EE05B8FC16 for ; Sun, 9 Aug 2009 19:55:17 +0000 (UTC) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:32944 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1MaEU2-0002Pi-5G; Sun, 09 Aug 2009 21:55:12 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 1D1FE191494; Sun, 9 Aug 2009 21:55:13 +0200 (CEST) Message-Id: <8934C698-C37D-4DB7-A7F5-4B93014AD0E9@exscape.org> From: Thomas Backman To: Rick Macklem In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 9 Aug 2009 21:55:10 +0200 References: <598778D3-AE7B-47AF-A4F9-0D832BC1A990@exscape.org> <00694EF2-9BBC-4733-91C7-A6AE973D8973@exscape.org> X-Mailer: Apple Mail (2.936) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MaEU2-0002Pi-5G. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MaEU2-0002Pi-5G 1171838591e9557bff3a142706d4ce10 Cc: FreeBSD current Subject: Re: nmap UDP scan against 8.0-CURRENT -> fatal trap 12 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 19:55:18 -0000 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=