Bug #2662
closedAnother NULL pointer dereference in networking code
Description
Hi!
I'am using the same configuration as described here:
https://bugs.dragonflybsd.org/issues/2660
After playing with my virtual machine for a while I caught a new kernel
panic caused by dereferencing a NULL pointer to network interface. As the
backtrace tells, it appears in in_broadcast():
(kgdb) bt
#0 _get_mycpu () at ./machine/thread.h:69
#1 md_dumpsys (di=di@entry=0xffffffff80f38f60 <dumper>) at
/usr/src/sys/platform/pc64/x86_64/dump_machdep.c:265
#2 0xffffffff80561832 in dumpsys () at
/usr/src/sys/kern/kern_shutdown.c:912
#3 0xffffffff802b21ac in db_fncall (dummy1=<optimized out>,
dummy2=<optimized out>, dummy3=<optimized out>, dummy4=<optimized out>)
at /usr/src/sys/ddb/db_command.c:539
#4 0xffffffff802b25e3 in db_command (aux_cmd_tablep_end=<optimized out>,
aux_cmd_tablep=<optimized out>, cmd_table=<optimized out>,
last_cmdp=0xffffffff80db5430 <db_last_command>) at
/usr/src/sys/ddb/db_command.c:401
#5 db_command_loop () at /usr/src/sys/ddb/db_command.c:467
#6 0xffffffff802b51b9 in db_trap (type=type@entry=12, code=code@entry=0)
at /usr/src/sys/ddb/db_trap.c:71
#7 0xffffffff809345ef in kdb_trap (type=type@entry=12, code=code@entry=0,
regs=regs@entry=0xffffffe05de9b7f8)
at /usr/src/sys/platform/pc64/x86_64/db_interface.c:174
#8 0xffffffff80939890 in trap_fatal (frame=frame@entry=0xffffffe05de9b7f8,
eva=<optimized out>) at /usr/src/sys/platform/pc64/x86_64/trap.c:1029
#9 0xffffffff80939ac9 in trap_pfault (frame=frame@entry=0xffffffe05de9b7f8,
usermode=usermode@entry=0) at /usr/src/sys/platform/pc64/x86_64/trap.c:934
#10 0xffffffff8093a015 in trap (frame=0xffffffe05de9b7f8) at
/usr/src/sys/platform/pc64/x86_64/trap.c:610
#11 0xffffffff809242af in calltrap () at
/usr/src/sys/platform/pc64/x86_64/exception.S:188
#12 0xffffffff8065da52 in in_broadcast (in=..., ifp=0x0) at
/usr/src/sys/netinet/in.c:1303
#13 0xffffffff8067aaa6 in tcp_input (mp=<optimized out>, offp=<optimized
out>, proto=<optimized out>) at /usr/src/sys/netinet/tcp_input.c:1147
#14 0xffffffff80671ce6 in transport_processing_oncpu (m=0x0, hlen=20,
ip=0xffffffe0f47c59c0) at /usr/src/sys/netinet/ip_input.c:390
#15 0xffffffff80671d1b in transport_processing_handler (msg=<optimized
out>) at /usr/src/sys/netinet/ip_input.c:404
#16 0xffffffff8061be6a in netmsg_service_loop (arg=<optimized out>) at
/usr/src/sys/net/netisr.c:319
#17 0xffffffff80571c57 in lwkt_deschedule_self (td=<optimized out>) at
/usr/src/sys/kern/lwkt_thread.c:327
#18 0x0000000000000000 in ?? ()
(kgdb) frame 12
#12 0xffffffff8065da52 in in_broadcast (in=..., ifp=0x0) at
/usr/src/sys/netinet/in.c:1303
warning: Source file is more recent than executable.
1303 if ((ifp->if_flags & IFF_BROADCAST) == 0)
(kgdb) quit
I don't know exactly how to reproduce the bug but it appears very often
(approx. every 10 minutes) with described configuration when machines A and
C access ftp server on machine B.
I attach a patch that checks if ipf is not NULL, which finally fixes the
problem.
I also checked sys/netinet/tcp_input.c for passing m->m_pkthdr.rcvif. Both
in_pcblookup_pkthash and in_pcblookup_hash seem to handle this argument
correctly.
Crash dump:
https://docs.google.com/uc?export=download&id=0B1NArWn4pLpxLVRCZmlld0VURGM
Files
Updated by tuxillo over 10 years ago
- Category set to Networking
- Status changed from New to In Progress
- Assignee set to tuxillo
- Target version set to 3.8
Hi,
I can't download the core file:
Bad Request
Error 400
Cheers,
Antonio Huete
Updated by tuxillo over 10 years ago
Nevermind, luxh downloaded it for me. Thanks.
Updated by shamaz over 10 years ago
Here is another link (just in case):
https://drive.google.com/uc?id=0B1NArWn4pLpxLVRCZmlld0VURGM&export=download
It's not direct, unfortunately. You will need to click "download" in browser.
Updated by tuxillo over 10 years ago
- Status changed from In Progress to Closed
- % Done changed from 0 to 100
Applied in changeset e988d4f263591098c001f5553d30897f66338012.