[Snort-devel] Re: Snort 2.0 build 45 core dump and fix

Chris Green cmg at ...402...
Fri Jan 24 10:11:02 EST 2003


"Lawrence Reed" <Lawrence.Reed at ...1489...> writes:

> Vital stats:  Snort 2.0 build 45
> Redhat 7.3  kernel 2.4.18-19.7.xsmp
> Sniffing a gige interface running between 80 -140 Mbits/Second
>
> With the stream4 reassmbley enable snort will only run for 1-2 hours
> before crashing.  After running gdb against the core and adding some
> LogMessage statements I have determined the cause of the crashes.  I
> am a little uncertain about the correctness of my fix though. 

Hrm. I wonder how we missed that before.  Good catch, I'll get it
fixed this weekend.

> The crash happens in ReassembleStream4 aftter the call to
> UpdateState around line 1742.  Apparently the UpdateState routine is
> setting the ACTION_DROP_SESSION bit in the return code.  The next
> thing that happens is a call to TCPAction, which correctly deletes
> (via DropSession) the current session (ssn) and sets p->ssnptr to
> NULL.  Then line 1763 calls StoreStreamPkt(ssn,p,pkt_seq) which uses
> the now deleted ssn structure. This is where the crash occurs, as
> shown in the backtrace below.  My solution is to move the
> StoreStreamPkt call to before TcpAction.

I would just change the

if(p->dsize && reassemble)
{
        StoreStreamPkt(ssn, p, pkt_seq);
}

to

if(p->dsize && p->ssnptr && && reassemble)
{
        StoreStreamPkt(ssn, p, pkt_seq);
}

That communication path needs to be cleaned up.

> This prevents the crash on my system. Snort has been running for 24
> hours. 

Try running the above fix and let me know how it goes. 

> Now my question is about the call to DropSession rather than
> FlushStream, then DropSession.  In this situation does the
> reassembled data at the end of the stream ever get processed? 

No it's not.  It probably should be.  The reason it's not (aside from
it being overlooked when first implemented) is we process a lot of
DropSessions when we are pruning because we're thrashing the memory
cache and processing more flushes causes a lot more work for the
system in that condition.

> I hope that makes sense.  Anyway here is the backtrace from the core
> file.  I still have this fille you anyone wants more info.

Thanks for the fixes Lawrence.


-- 
Chris Green <cmg at ...402...>
 "Not everyone holds these truths to be self-evident, so we've worked
                  up a proof of them as Appendix A." --  Paul Prescod




More information about the Snort-devel mailing list