Re: segfault while running snort 2.9.0.5 on CentOS 5.6

[Michael Altizer <xiche () verizon net>]

On 04/19/2011 11:32 PM, Charles Low wrote:
> Hi,
>
> I am encountering a segmentation fault when running my own compile snort
> on CentOS 5.6 (x86_64). It appears randomly, and I am not familiar to
> handling such, so would like to ask for your help to troubleshoot the
> cause of problem. Thanks for your help in advance.
>
> I am using pulledpork to fetch VRT subscribed rules with so rules enabled
> (based on RHEL-5-5 precompiled rules)
>
> dmesg
> ------
> snort[2255]: segfault at 0000000000000000 rip 00000000004ed9e6 rsp
> 00007fff04aad120 error 4
>
> gdb output (attached to the running snort process which compiled with
> –enable-debug and –enable-debug-msg)
> -----------
>
> Reading symbols from
> /usr/local/lib/snort_dynamicpreprocessor//libsf_ftptelnet_preproc.so...don
> e.
> Loaded symbols for
> /usr/local/lib/snort_dynamicpreprocessor//libsf_ftptelnet_preproc.so
> Reading symbols from
> /usr/local/lib/snort_dynamicpreprocessor//libsf_ssh_preproc.so...done.
> Loaded symbols for
> /usr/local/lib/snort_dynamicpreprocessor//libsf_ssh_preproc.so
>
> warning: no loadable sections found in added symbol-file system-supplied
> DSO at 0x7fffa5ba7000
> 0x00000000004eb050 in sflist_next (s=0x138e8180) at sflsq.c:219
> 219             if( s->cur )
> (gdb) continue
> Continuing.
> [New Thread 0x40e83940 (LWP 2274)]
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00000000004ed9e6 in sfxhash_find_node_row (t=0x0, key=0x7fffa5a01f20,
> rindex=0x7fffa5a01ed4)
>      at sfxhash.c:719
> 719         hashkey = t->sfhashfcn->hash_fcn( t->sfhashfcn,
> (gdb) backtrace
> #0  0x00000000004ed9e6 in sfxhash_find_node_row (t=0x0,
> key=0x7fffa5a01f20,
>      rindex=0x7fffa5a01ed4) at sfxhash.c:719
> #1  0x00000000004edd4b in sfxhash_find (t=0x0, key=0x7fffa5a01f20) at
> sfxhash.c:937
> #2  0x000000000049dde5 in findFlowIPStats (sfFlow=0x134a220,
> src_addr=0x29384a40,
>      dst_addr=0x29384a58, swapped=0x7fffa5a01f94) at perf-flow.c:334
> #3  0x000000000049e1db in UpdateFlowIPState (sfFlow=0x134a220,
> src_addr=0x29384a40,
>      dst_addr=0x29384a58, state=SFS_STATE_UDP_CREATED) at perf-flow.c:383
> #4  0x00000000004e4fe8 in NewUdpSession (p=0x7fffa5a02240,
> lwssn=0x29384a10,
>      s5UdpPolicy=0x12070600) at snort_stream5_udp.c:414
> #5  0x00000000004e5661 in ProcessUdp (lwssn=0x29384a10, p=0x7fffa5a02240,
>      s5UdpPolicy=0x12070600) at snort_stream5_udp.c:598
> #6  0x00000000004e529f in Stream5ProcessUdp (p=0x7fffa5a02240,
> lwssn=0x29384a10,
>      s5UdpPolicy=0x12070600, skey=0x7fffa5a020d0) at
> snort_stream5_udp.c:532
> #7  0x00000000004b6e9a in Stream5Process (p=0x7fffa5a02240, context=0x0)
> at spp_stream5.c:1199
> #8  0x0000000000444b17 in Preprocess (p=0x7fffa5a02240) at detect.c:176
> #9  0x0000000000437982 in ProcessPacket (user=0x0, pkthdr=0x7fffa5a03090,
>      pkt=0x2aaaaaaac042 "\377\377\377\377\377\377\b", ft=0x0) at
> snort.c:1480
> #10 0x00000000004375d0 in PacketCallback (user=0x0, pkthdr=0x7fffa5a03090,
>      pkt=0x2aaaaaaac042 "\377\377\377\377\377\377\b") at snort.c:1394
> #11 0x000000000050c775 in pcap_process_loop (user=0x29384240
> "\260\272\367(",
>      pkth=<value optimized out>, data=0x7fffa5a01ed4 "") at daq_pcap.c:357
> #12 0x00002baa3668ee4a in pcap_read_linux_mmap () from
> /usr/local/lib/libpcap.so.1
> #13 0x000000000050cbdb in pcap_daq_acquire (handle=0x29384240, cnt=-1,
>      callback=<value optimized out>, user=<value optimized out>) at
> daq_pcap.c:375
> #14 0x000000000045ba20 in DAQ_Acquire (max=-1, callback=0x437421
> <PacketCallback>, user=0x0)
>      at sfdaq.c:457
> #15 0x0000000000439e60 in PacketLoop () at snort.c:2777
> #16 0x0000000000436525 in SnortMain (argc=3, argv=0x7fffa5a03328) at
> snort.c:729
> #17 0x000000000043641e in main (argc=3, argv=0x7fffa5a03328) at
> snort.c:661
>
> Best regards,
>
> Charles Low
Looks like a poor interaction between Perfmon+FlowIP and Snort Reload. 
It will be triggered if you enable FlowIP tracking in the Performance 
Monitor preprocessor between restart-less reloads (--enable-reload + 
SIGHUP). Does that sound like what you're doing?

-Michael


------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users