[Snort-devel] [BUG][Stream5]: SIGSEGV in Stream5 TCP, TcpSessionCleanup at snort_stream5_tcp.c:4624

Joshua.Kinard at ...3108... Joshua.Kinard at ...3108...
Fri Oct 7 02:06:41 EDT 2011


Hi snort-devel,

Running some tests on a large dataset, I seem to have uncovered a
SIGSEGV in Stream5 TCP reassembly when it tries to flush the TCP stream
at a specific point.  Here is the GDB backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x00000000004dcf3b in TcpSessionCleanup (lwssn=0x8f061c0) at
snort_stream5_tcp.c:4624
4624                flushed = flush_stream(tcpssn, &tcpssn->server, &p,
(gdb) bt
#0  0x00000000004dcf3b in TcpSessionCleanup (lwssn=0x8f061c0) at
snort_stream5_tcp.c:4624
#1  0x00000000004eed0d in DeleteLWSession (sessionCache=0x1643a30,
ssn=0x8f061c0, delete_reason=0x56363e "purge whole cache") at
snort_stream5_session.c:632
#2  0x00000000004eeed0 in PurgeLWSessionCache (sessionCache=0x1643a30)
at snort_stream5_session.c:704
#3  0x00000000004d97ee in Stream5ResetTcp () at snort_stream5_tcp.c:2041
#4  0x00000000004b9225 in Stream5Reset (signal=-1, foo=0x0) at
spp_stream5.c:932
#5  0x000000000043a563 in SnortReset () at snort.c:2878
#6  0x000000000043706b in PQ_Reset () at snort.c:1013
#7  0x0000000000437176 in PQ_Next () at snort.c:1072
#8  0x000000000043a4aa in PacketLoop () at snort.c:2820
#9  0x0000000000436ab9 in SnortMain (argc=10, argv=0x7fffffffe318) at
snort.c:740
#10 0x00000000004369b2 in main (argc=10, argv=0x7fffffffe318) at
snort.c:672


I tried following the code flow in GDB, but flush_stream is an inlined
function, and the SIGSEGV appears to happen at the point during the
function jump.  Not sure if it's an issue with the compiler doing
something funny or not.  This happens on both Snort 2.9.1 and 2.9.1.1.

Toolchain info:
gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-51)
GNU ld version 2.17.50.0.6-14.el5 20061020
GNU assembler 2.17.50.0.6-14.el5 20061020

GNU C Library stable release version 2.5, by Roland McGrath et al.
Compiled by GNU CC version 4.1.2 20080704 (Red Hat 4.1.2-50).
Compiled on a Linux 2.6.9 system on 2011-04-08.



The bug (so far) appears reproducable with a standard stream5
configuration, no rules, and a very specific PCAP file publicly
available on the web.

My minimal configuration:

preprocessor frag3_global:    \
    max_frags 65536,          \
    prealloc_frags 65536,     \
    memcap 67108864

preprocessor stream5_global:  \
    track_tcp yes,            \
    track_udp yes,            \
    max_tcp 1048576,          \
    max_udp 1048576

preprocessor stream5_tcp:     \
    timeout 600,              \
    overlap_limit 0,          \
    max_window 0,             \
    ports both                \
        21 23 25 53 80 110    \
        135 136 137 139 143   \
        389 443 445 636 993   \
        1433 1521 3306        \
        6666 6667 6668 6669   \
        5222 8443 8080

preprocessor stream5_udp:     \
    timeout 600

config paf_max: 63780
config flowbits_size: 256
config daq: pcap
config daq_mode: read-file


And the PCAP file is "Border Data Capture 3/8" from the ITOC/CDX 2009
Datasets (95MB download):
http://www.itoc.usma.edu/research/dataset/data/2009-04-21-07-47-35.dmp


Hope that helps.  Cheers!

--J




More information about the Snort-devel mailing list