[Snort-devel] I think I got it
cpw at ...86...
Mon Jul 30 23:36:57 EDT 2001
On Mon, Jul 30, 2001 at 08:48:32PM -0400, Jed Pickel wrote:
> You are quite the bug hunter! Thanks for taking the database plugin
> off the hook. :) It still strikes me as strange that (at least in your
> case) other bugs manifesting were dependent on whether or not the db
Not strange, all the plugins are using malloc/free to do their job.
stream4 free'd an array, but neglected to remove a memory of the pointer
which is needed further along in the detect cycle for the particular
stream, so that it can be flushed (AlertFlushStream). Unfortunately,
p->ssnptr was pointing to memory that had been free'd because the input
plugin had realized that the packet was so bogus, it could not be part
of a real stream. (at least that's my take. it could be for some other
reason entirely. I'm new to this application).
It just so happened that the database plugin was did a malloc and got
a buffer which coincided with some of the old stream4 space. If it
wasn't your process, it could have been another output process that
did some malloc's.
> plugin was enabled. So I'll experiment with removing the malloc/free
> cycle for each alert and see if using automatic variables changes
I believe that you could get away with creating the necessary storage
either statically, or when called as local arrays. I would pick which
ever method caused the least number of cycles. I like static, cause
memory is cheap and you formalize the use and can't interfer with other
routines. I think that would cut down on alot of malloc / free subroutine
However, any system which is as complex as snort, can, with a little
mind fart, modify any memory currently assigned to the process.
> * Jed
Phil Wood, cpw at ...86...
More information about the Snort-devel