[Snort-devel] Crash in AC SparseBands

Marc Norton mnorton at ...402...
Mon Dec 4 14:49:55 EST 2006

There was a bug in ac-sparsebands in the 2.6.0 series, that could cause 
a segv.  It is fixed in the 2.6.1 series. Also, in the 2.6.1 series you 
should use the 'ac-bnfa' search method. It uses very little memory 
compared to all of the previous 'ac' methods, and is about 95-100% of 
the same speed. This will become our default soon.

Matthew Hall wrote:
> Hi Snort Devs,
> We've been running snort (, with the 'ac-sparsebands' config
> detection type and have run into a few crashes (SEGV).
> A little info about the box - it has 2 snort daemons running side by
> side on a single, separate (gigabit) interface each. Though it usually
> only sees around 2Mbps we've seen peaks at ~45Mbps occasionally, and are
> running with PCAP_FRAMES=max. It's a pretty beefy box so load hardly
> reaches 1.0, sitting around 0.5 on a normal day.
> I've got snort running in debug mode under gdb (under screen, and it's
> still open if you need me to prod the stack); backtrace follows.
> (gdb) bt
> #0  0x080cde76 in acsmSearchSparseDFA (acsm=0xc33f038,
>     Tx=0x98a8a70
> "\uffff`\uffff\017\n\uffff\uffff4L\uffffc\u036e\033\uffff\uffff\020c\uffffHa\022\227(?Oy\uffff\uffff]\u07e2\036\032Gn\uffff",
> n=1460, Match=0x80703db <otnx_match>, data=0x81067e0) at acsmx2.c:1933
> #1  0x080ce6f1 in acsmSearch2 (acsm=0xc33f038,
>     Tx=0x98a8a70
> "\uffff`\uffff\017\n\uffff\uffff4L\uffffc\u036e\033\uffff\uffff\020c\uffffHa\022\227(?Oy\uffff\uffff]\u07e2\036\032Gn\uffff",
> n=1460, Match=0x80703db <otnx_match>, data=0x81067e0) at acsmx2.c:2240
> #2  0x080c6821 in mpseSearch (pvoid=0xc1bdc98,
>     T=0x98a8a70
> "\uffff`\uffff\017\n\uffff\uffff4L\uffffc\u036e\033\uffff\uffff\020c\uffffHa\022\227(?Oy\uffff\uffff]\u07e2\036\032Gn\uffff",
>     n=1460, action=0x80703db <otnx_match>, data=0x81067e0) at mpse.c:303
> #3  0x08070eb3 in fpEvalHeaderSW (port_group=0xb52d7f0, p=0xbfa00f58,
>     check_ports=1) at fpdetect.c:1385
> #4  0x080711ea in fpEvalHeaderTcp (p=0xbfa00f58) at fpdetect.c:1558
> #5  0x080714a3 in fpEvalPacket (p=0xbfa00f58) at fpdetect.c:1731
> #6  0x0806a275 in Detect (p=0xbfa00f58) at detect.c:480
> #7  0x08069c9b in Preprocess (p=0xbfa00f58) at detect.c:157
> #8  0x08061cdd in ProcessPacket (user=0x0, pkthdr=0xbfa01328,
>     pkt=0x98a8a3a "", ft=0x0) at snort.c:1291
> #9  0x08061aad in PcapProcessPacket (user=0x0, pkthdr=0xbfa01328,
>     pkt=0x98a8a3a "") at snort.c:1202
> #10 0xb7d67970 in pcap_platform_finddevs () from /usr/lib/libpcap.so.0.8.3
> #11 0xb7d69107 in pcap_dispatch () from /usr/lib/libpcap.so.0.8.3
> #12 0x0806401e in InterfaceThread (arg=0x0) at snort.c:2618
> #13 0x08061632 in SnortMain (argc=16, argv=0xbfa01524) at snort.c:1019
> #14 0x08060bf1 in main (argc=16, argv=0xbfa01524) at snort.c:345
> I've not tried 2.6.1(.1) yet - but am happy to if any devs can say there
> were bugs in the AC implementation which might've been fixed...
> I'm not sure if this is related - but we've had a few alerts generated
> on the interface the debug snort is running under which seem to be
> corrupted (all of these alerts come from 'snort_decoder').
> When converting the unified log to pcap via barnyard, wireshark/ethereal
> sees that the tcp options are offset by 12bytes; ie. wireshark
> recognises the end of the tcp header as the start of some tcp options,
> but it is actually the top of the data portion of the packet.
> I'm not sure if this is a wireshark bug or not, but I can't find similar
> packets when pulling straight from the wire, and have only seen this on
> packets being processed through snort into a unified log (and then to
> pcap via barnyard).
> Cheers,
> Matthew Hall
> Security Engineer
> ECSC Ltd
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Snort-devel mailing list
> Snort-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/snort-devel

Marc Norton      Snort Team Lead
Sourcefire,Inc   410-423-1924
www.snort.org    www.sourcefire.com 

More information about the Snort-devel mailing list