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

On Aug 9, 2009, at 20:25, Rick Macklem wrote:

>
>
> On Sun, 9 Aug 2009, Thomas Backman wrote:
>
> [stuff snipped]
>> Fatal trap 12: page fault while in kernel mode
>> cpuid = 0; apic id = 00
>> fault virtual address   = 0x18
>> fault code      = supervisor read data, page not present
>> instruction pointer = 0x20:0xffffffff805d2722
>> stack pointer           = 0x28:0xffffff803e76f980
>> frame pointer           = 0x28:0xffffff803e76f990
>> code segment        = base 0x0, limit 0xfffff, type 0x1b
>> 				= DPL 0, pres 1, long 1, def32 0, gran 1
>> processor eflags    = interrupt enabled, resume, IOPL = 0
>> current process     = 846 (nfsd: service) [NOTE: nfsd was not in  
>> use, merely running]
>> panic: from debugger
>> cpuid = 0
>> KDB: stack backtrace:
>> Uptime: 8m48s
>> Physical memory: 2029 MB
>> Dumping 1625 MB: ...
>>
>> #11 0xffffffff805dba87 in calltrap ()    at /usr/src/sys/amd64/ 
>> amd64/exception.S:224
>> #12 0xffffffff805d2722 in xdrmbuf_inline (xdrs=0xffffff803e76fa30,  
>> len=4)
>>  at /usr/src/sys/xdr/xdr_mbuf.c:302
>> #13 0xffffffff805d2b90 in xdrmbuf_getlong (xdrs=0xffffff803e76fa30,
>>  lp=0xffffff803e76f9e0) at /usr/src/sys/xdr/xdr_mbuf.c:147
>> #14 0xffffffff805d1a4d in xdr_int (xdrs=Variable "xdrs" is not  
>> available.
>> ) at /usr/src/sys/xdr/xdr.c:111
>> #15 0xffffffff80554ef4 in xdr_callmsg (xdrs=0xffffff803e76fa30,  
>> cmsg=0xffffff803e76fb70) at /usr/src/sys/rpc/rpc_callmsg.c:188
>> #16 0xffffffff80559c60 in svc_dg_recv (xprt=Variable "xprt" is not  
>> available.
>> ) at /usr/src/sys/rpc/svc_dg.c:216
>> #17 0xffffffff80557910 in svc_run_internal (pool=0xffffff00027acc00,
>>  ismaster=0) at /usr/src/sys/rpc/svc.c:797
>> #18 0xffffffff8055811b in svc_thread_start (arg=Variable "arg" is  
>> not available.
>> )    at /usr/src/sys/rpc/svc.c:1198
>> #19 0xffffffff80341008 in fork_exit (
>>  callout=0xffffffff80558110 <svc_thread_start>,  
>> arg=0xffffff00027acc00,
>>  frame=0xffffff803e76fc80) at /usr/src/sys/kern/kern_fork.c:838
>> #20 0xffffffff805dbf5e in fork_trampoline ()    at /usr/src/sys/ 
>> amd64/amd64/exception.S:561
>> #21 0x0000000000000010 in ?? ()
>> #22 0x00007fffffffe710 in ?? ()
>> ...
>> #47 0x0000000000000000 in ?? ()
>> #48 0xffffffff808acf00 in affinity ()
>> #49 0xffffff0002d9d390 in ?? ()
>> #50 0xffffff803e76f200 in ?? ()
>> #51 0xffffff803e76f1b8 in ?? ()
>> #52 0xffffff0002336720 in ?? ()
>> #53 0xffffffff80391c2d in sched_switch (td=0xffffffff80558110,
>>  newtd=0xffffff00027acc00, flags=Variable "flags" is not available.
>> ) at /usr/src/sys/kern/sched_ule.c:1858
>>
> You could try this patch, which is currently in the re_at_ queue. I'm not
> sure if it will help, since the above panic didn't seem to happen at
> the beginning of xdrmbuf_inline() as I would have expected it to.
>
> rick
> --- 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
> _at__at_ -282,6 +282,8 _at__at_
> 	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.

Regards/thanks,
Thomas