[Snort-devel] Re: Big memory leaks in snort 2.0.2

Martin Roesch roesch at ...402...
Sun Sep 21 18:21:02 EDT 2003


This has been in Snort for almost 5 years and is well known, since it's 
in the parsing/startup code it's never been something that's been on 
the "fix now" list.  We're looking at fixing it once and for all right 
now, stay tuned and we should have it worked out this week.

      -Marty


On Sunday, September 21, 2003, at 01:25  PM, Steve G wrote:

> Hello,
>
> First, thanks to everyone that has worked on making snort the
> great tool it is!
>
> Secondly, I have a bug report. The obligitory info:
>
> System Architecture: x86
> Operating System and version: RH 8.0, 2.4.20 kernel
> Version of Snort: 2.0.2
>
> Snort is leaking massive amounts of memory. The problem starts in
> the parsers by calling mSplit().
>
> mSplit makes a series of calls to malloc. The first is to
> allocate an array for the pointers of tokens it will return. Then
> it makes a call to malloc for each token it finds.
>
> grep'ing around the source code, most functions that call mSplit
> fail to free anything returned by mSplit. Functions that do free
> anything always forget to free the memory that holds the array of
> pointers. Normally, this is toks or pp_head.
>
> With a normal ruleset downloaded from snort.org, I get about 600k
> of lost memory. Now thow in a few kill -HUPs and the memory loss
> multiplies. The leaks can be much worse depending on what
> preprocessors you have enabled.
>
> I started patching this problem and quickly realized this is a
> big problem and more people should know about this and help patch
> it. I would recommend patching all these memory leaks and
> releasing a 2.0.3 that covers just the memory leaks...no new
> features.
>
> To see the mSplit memory leaks first hand, try this:
>
> valgrind --leak-check=yes --leak-resolution=high --num-callers=8
> --logfile-fd=19  /usr/sbin/snort -u snort -g snort -d  -c
> /etc/snort/snort.conf  19> log.txt
>
> Let snort come up and then send it a sigterm. sigkill causes
> valgrind to abort instead of do the leak check. Valgrind reports
> other problems in the application, but lets solve the memory
> leaks first. The output of valgrind is in log.txt of your current
> directory.
>
> Here's a sample valgrind error record:
>
> ==9704== 760 bytes in 19 blocks are definitely lost in loss
> record 199 of 208
> ==9704==    at 0x40025394: malloc (vg_replace_malloc.c:153)
> ==9704==    by 0x804F834: mSplit (../../../src/mstring.c:143)
> ==9704==    by 0x8050531: ParseRule (../../../src/parser.c:481)
> ==9704==    by 0x804FF31: ParseRulesFile
> (../../../src/parser.c:252)
> ==9704==    by 0x805596E: SnortMain (../../../src/snort.c:461)
> ==9704==    by 0x80555B6: main (../../../src/snort.c:166)
> ==9704==    by 0x402E14EC: __libc_start_main (in
> /lib/libc-2.3.2.so)
> ==9704==    by 0x804A288: (within /usr/sbin/snort-mysql)
>
>
> I have attached a patch to this e-mail that starts the cleanup
> process. Much more work needs to be done, though.
>
> Best Regards,
> -Steve Grubb
>
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com<snort-2.0.2-memleak1.patch>
-- 
Martin Roesch - Founder/CTO Sourcefire Inc. - (410) 290-1616
Sourcefire: Enterprise-class Intrusion detection built on Snort
roesch at ...402... - http://www.sourcefire.com
Snort: Open Source Network IDS - http://www.snort.org





More information about the Snort-devel mailing list