search

mcr / tcpdump

the TCPdump network dissector. now moved to:
https://github.com/the-tcpdump-group/tcpdump
Other
84 stars 2 forks source link

coredump when launched in a ESX4 VM without interface parameter #59

Closed JoKoT3 closed 11 years ago

JoKoT3 commented 11 years ago

tcpdump version 4.3.0 libpcap version 1.3.0 Systems : both systems are arch x64 up-to-date, one is an ESX 4 VM, the other is a dell laptop

Error : tcpdump core dumps when lauched without -i parameter in a VM running on ESX 4. The same command does not produce a core dump when launched on my laptop Both are ok when specifying an interface.

strace when core dump : http://pastebin.com/Md6btdcn gdb backtrace of the coredump : http://pastebin.com/zB2JFgsC

let me now if I can provide more information, the crash being reproducible.

mcr commented 11 years ago

I have opened a ticket on libusb.org, when it is approved, I will post the link here.

mcr commented 11 years ago

On Mar 26, 2013, at 9:07 AM, Michael Richardson mcr@sandelman.ca wrote:

The fault seems to be inside of libusb:

Using host libthread_db library "/usr/lib/libthread_db.so.1". Core was generated by `/usr/sbin/tcpdump icmp'. Program terminated with signal 11, Segmentation fault.

0 0x00007feae033fb50 in __opendirat () from /usr/lib/libc.so.6

(gdb) bt

0 0x00007feae033fb50 in __opendirat () from /usr/lib/libc.so.6

1 0x00007feadfc68e9e in ?? () from /usr/lib/libusb-1.0.so.0

2 0x00007feadfc6153c in libusb_get_device_list () from

/usr/lib/libusb-1.0.so.0

3 0x00007feae0647a9f in canusb_platform_finddevs () from

/usr/lib/libpcap.so.1

It appears that it faults if there are no USB devices, which wouldn't be surprising for a VM.

It faults because it's being handed a NULL first argument, and it's being handed a NULL argument because libpcap isn't checking whether libusb_init() succeeded or not.

So, while it's crashing inside libusb, that's because libpcap wasn't using libusb correctly. If you've filed a libusb bug, you might want to close it.

This bug was fixed last year in

commit 9f8827ee41bbf24c7dc98d5f6ff3790756e378f4 Author: Guy Harris guy@alum.mit.edu Date: Mon Aug 6 15:25:30 2012 -0700

Check whether libusb_init() succeeds, and give up if it doesn't.

libusb_init() isn't guaranteed to succeed; it returns a (presumably)
non-zero error on failure.  If it doesn't return 0, just give up - we
presumably don't have a valid libusb_context pointer, which is probably
what's causing crashes when we call libusb_get_device_list() on a system
with no usbfs mounted.

This fixes bug 3554749 in the tracker, and a bunch of upstream bugs.