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

Lawrence Reed Lawrence.Reed at ...1489...
Fri Jan 24 11:54:09 EST 2003


Chris Green wrote:

>"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.
>  
>
The reason I didn't do that is so that when the action from UpdateState 
is *_FLUSH_STREAM| DROP_SESSION the current packet gets put onto the 
stream before the flush happens ( form inside TcpAction).  The 
FlushStream does call BuildPacket and therefore process the reassembled 
data.  Is this wrong?

>  
>
>>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.
>
>
>  
>






More information about the Snort-devel mailing list