Jolt2 crashes tcpdump

[ecarter () CISCO COM (Earl T. Carter)]

I was testing the effects of jolt2 on a Win2K system in our lab.  The command line options were:

    jolt2 x.y.z.q

As advertised, this caused the win2K to freeze.  At the same time, I was watching the network traffic on a Redhat Linux 
6.0 system using tcpdump.  After I killed the Jolt2 process, the Win2K box was back to normal, but the Linux box was 
completely locked up.  The Linux machine required a hard reset to get it operational again.  The command that I used on 
the tcpdump command line was:

    tcpdump -n -s 1500 -w /tmp/filename

After some quick testing, I discovered that the Linux box would not lock up if the network traffic is output to the 
screen.  I also discovered that using the default snaplen and writing to a file does not cause a problem.  The lock up 
seems to only occur when you specify a snaplen of 1500 (entire Ethernet packet) and use Tcpdump's 
"-w" command to write the sniffed packets to a file.  It only takes about 5 seconds worth of jolt2 traffic to cause the 
Linux box to lock up.

The same problem appears on the latest version of tcpdump (3.4.a6).  I have not tested the latest Alpha version (3.5), 
nor have I tested any other versions of tcpdump other than the two that I have listed.  If I find out any more 
information in my further testing, I will forward it on to the bugtraq mailing list.

P.S. I am sending this to the bugtraq mailing list, since I do not know who is in charge of updates to the Tcpdump 
Software.

Earl Carter
Security Research Engineer

ecarter () cisco com