Date: Sun, 25 Oct 1998 01:23:08 -0800 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: Kris Kennaway <kkennawa@physics.adelaide.edu.au>, Don Lewis <Don.Lewis@tsc.tdk.com>, dfr@nlsystems.com, wollman@khavrinen.lcs.mit.edu Cc: current@FreeBSD.ORG Subject: Re: nestea v2 against freebsd 3.0-Release (fwd) Message-ID: <199810250923.BAA25064@salsa.gv.tsc.tdk.com> In-Reply-To: Kris Kennaway <kkennawa@physics.adelaide.edu.au> "Re: nestea v2 against freebsd 3.0-Release (fwd)" (Oct 25, 1:25am)
next in thread | previous in thread | raw e-mail | index | archive | help
On Oct 25, 1:25am, Kris Kennaway wrote:
} Subject: Re: nestea v2 against freebsd 3.0-Release (fwd)
} On Sat, 24 Oct 1998, Don Lewis wrote:
}
} > } rootshell.com has a .tgz containing a linux compiled binary - that's the one I
} > } ran [1]. Perhaps it was the linuxulator which crashed me, instead of what the
} > } program itself did.
} >
} > Could be. Can you get a stack trace, either with DDB, or with a crash dump
} > and gdb?
}
} (kgdb) where
} #0 boot (howto=260) at ../../kern/kern_shutdown.c:268
} #1 0xf012f5e8 in at_shutdown (function=0xf0227772 <db_panic_cmd+22>,
} arg=0xf2c7dc34, queue=-267277140) at ../../kern/kern_shutdown.c:430
} #2 0xf011acfd in db_panic (addr=-266858820, have_addr=0, count=-1,
} modif=0xf2c7dbbc "") at ../../ddb/db_command.c:432
} #3 0xf011acac in db_command (last_cmdp=0xf0240c34, cmd_table=0xf0240a94,
} aux_cmd_tablep=0xf02550b4) at ../../ddb/db_command.c:332
} #4 0xf011ad62 in db_command_loop () at ../../ddb/db_command.c:454
} #5 0xf011d4f3 in db_trap (type=12, code=0) at ../../ddb/db_trap.c:71
} #6 0xf01e545d in kdb_trap (type=12, code=0, regs=0xf2c7dd00)
} at ../../i386/i386/db_interface.c:157
} #7 0xf01f13eb in trap_fatal (frame=0xf2c7dd00) at ../../i386/i386/trap.c:874
} #8 0xf01f10e4 in trap_pfault (frame=0xf2c7dd00, usermode=0)
} at ../../i386/i386/trap.c:772
} #9 0xf01f0d27 in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = -263534592,
} tf_esi = -263533804, tf_ebp = -221782688, tf_isp = -221782744,
} tf_ebx = 0, tf_edx = 0, tf_ecx = 0, tf_eax = 0, tf_trapno = 12,
} tf_err = 0, tf_eip = -266858820, tf_cs = 8, tf_eflags = 66118,
} tf_esp = -263533804, tf_ss = -266075918}) at ../../i386/i386/trap.c:396
} #10 0xf0180ebc in ip_reass (m=0xf04ac800, fp=0xf04acb14, where=0xf025bfc8)
} at ../../netinet/ip_input.c:802
} #11 0xf0180c3f in ip_input (m=0xf04ac800) at ../../netinet/ip_input.c:585
} #12 0xf0181bdb in ipintr () at ../../netinet/ip_input.c:669
} #13 0xf01e72c9 in swi_net_next ()
} #14 0xf0148c40 in sendit (p=0xf2c69880, s=3, mp=0xf2c7debc, flags=0)
} at ../../kern/uipc_syscalls.c:484
} #15 0xf0148e8b in sendmsg (p=0xf2c69880, uap=0xf2c7defc)
} at ../../kern/uipc_syscalls.c:632
} #16 0xf0222a5b in linux_sendto_hdrincl (p=0xf2c69880, bsd_args=0xf2c7df1c)
} at ../../i386/linux/linux_socket.c:245
} #17 0xf0223435 in linux_socketcall (p=0xf2c69880, args=0xf2c7df84)
} at ../../i386/linux/linux_socket.c:624
} #18 0xf01f15f7 in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = -272639092,
} tf_esi = 0, tf_ebp = 16, tf_isp = -221782060, tf_ebx = 11, tf_edx = 11,
} tf_ecx = -272639160, tf_eax = 102, tf_trapno = 12, tf_err = 2,
} tf_eip = 671593638, tf_cs = 31, tf_eflags = 534, tf_esp = -272639180,
} tf_ss = 39}) at ../../i386/i386/trap.c:1031
} #19 0xf01e5dec in Xint0x80_syscall ()
} Cannot access memory at address 0x10.
} (kgdb) quit
Ok, I figured out what's going on. When I compiled the nestea2.c under
FreeBSD, it didn't run at all because rip_output() does some sanity
checking between ip_len in the packet and the actual packet length, so
it doesn't send the third fragment and causes sendto() to return
EINVAL. The Linux emulation code in the kernel is kind enough to fix
ip_len, so the sanity check passes. Even after I fixed this in
nestea2.c, running it still didn't cause the system to panic. The
reason for this is some differences in byte swapping in the IP header
fields between Linux and FreeBSD that nestea2.c attempted to compensate
for, but didn't get right. Once I fixed the byte swapping problem, I
got the same panic you did, except for the linux emulation which I was
not using.
The panic is caused by a bug in the new ip fragment reassembly code
that can be provoked into playing with an mbuf after it has been freed.
Here's a patch.
--- ip_input.c.orig Fri Oct 23 02:17:19 1998
+++ ip_input.c Sun Oct 25 01:50:20 1998
@@ -750,7 +750,7 @@
* if they are completely covered, dequeue them.
*/
for (; q != NULL && ip->ip_off + ip->ip_len > GETIP(q)->ip_off;
- p = q, q = nq) {
+ q = nq) {
i = (ip->ip_off + ip->ip_len) -
GETIP(q)->ip_off;
if (i < GETIP(q)->ip_len) {
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810250923.BAA25064>