[syslog-ng] segfault in 3.4 alpha1

[Balazs Scheidler]

On Wed, 2012-03-14 at 08:10 +0100, Gergely Nagy wrote:
> Peter Czanik <czanik at balabit.hu> writes:
> 
> > Hello,
> >
> > I tried to compile and run alpha1 on openSUSE 12.1 and FreeBSD 8.1. I 
> > got a segfault on start on both. Here are the backtraces:
> 
> A little more info about this:
> 
> $ sbin/syslog-ng
> syslog-ng: Error setting capabilities, capability management disabled; error='Operation not permitted'
> WARNING: Configuration file format is too old, please update it to use the 3.4 format as some constructs might operate inefficiently;
> *** glibc detected *** sbin/syslog-ng: double free or corruption (fasttop): 0x00000000011508e0 ***
> ======= Backtrace: =========
> /lib/x86_64-linux-gnu/libc.so.6(+0x75ab6)[0x7f2c4318dab6]
> /lib/x86_64-linux-gnu/libc.so.6(cfree+0x6c)[0x7f2c431927ec]
> /home/algernon/install/sng/3.4/lib/syslog-ng/libafmongodb.so(afmongodb_parse+0xf4e)[0x7f2c4021765d]
> /home/algernon/install/sng/3.4/lib/libsyslog-ng-3.4.0alpha0.so(+0x4caa8)[0x7f2c44a6eaa8]
> /home/algernon/install/sng/3.4/lib/libsyslog-ng-3.4.0alpha0.so(plugin_parse_config+0x174)[0x7f2c44a6f201]
> /home/algernon/install/sng/3.4/lib/libsyslog-ng-3.4.0alpha0.so(main_parse+0x108a)[0x7f2c44a83aba]
> /home/algernon/install/sng/3.4/lib/libsyslog-ng-3.4.0alpha0.so(+0x23528)[0x7f2c44a45528]
> /home/algernon/install/sng/3.4/lib/libsyslog-ng-3.4.0alpha0.so(cfg_run_parser+0x124)[0x7f2c44a46171]
> /home/algernon/install/sng/3.4/lib/libsyslog-ng-3.4.0alpha0.so(cfg_read_config+0x84)[0x7f2c44a4628d]
> /home/algernon/install/sng/3.4/lib/libsyslog-ng-3.4.0alpha0.so(main_loop_init+0xa9)[0x7f2c44a68ed9]
> sbin/syslog-ng(main+0x1cf)[0x401994]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd)[0x7f2c43136ead]
> sbin/syslog-ng[0x401549]
> 
> Working from here:
> 
> #5  0x00007ffff332665d in afmongodb_parse (lexer=0x61d6f0, instance=0x7fffffffa870, arg=0x0) at afmongodb-grammar.y:799
> 799		| KW_REPLACE '(' string string ')' { value_pairs_transform_set_add_func(last_vp_transset, value_pairs_new_transform_replace($3, $4)); free($3); free($4); }

Something clobbers the heap before the free calls, running under
valgrind would probably reveal the cause.

However I'd need your configuration to get more information.

> 
> I tried playing with GDB and breaking after
> value_pairs_transform_set_add_func(), to see where things get freed
> twice, but after a few minutes of not being able to make heads and tails
> out of the bison-generated code I gave up.
> 
> But perhaps the above will shed some light on where the problem may
> be. The next step I'd take is try to find a version of 3.4 that works,
> and git bisect.
> 
> It does look like the problem is somewhere in the grammar stuff, as both
> backtraces come from ${module}_parse, and it affects multiple modules.

I don't think so, the one found by Peter is probably related to the new
file-perm specifying code, which may not have been properly used in the
afsocket module.

Now as I was second guessing it, I've found the culprit, it is fixed
here:

commit daded120cefa7217dac0b1a5d9a870a7fa7fc51d
Author: Balazs Scheidler <bazsi at balabit.hu>
Date:   Wed Mar 14 09:54:35 2012 +0100

    unix-dgram: fixed crash in file permission parsing code
    
    A line to set last_file_perm_options was missed in the unix-dgram variant
    of afsocket, which caused the last_file_perm_options variable to be
    initialized to NULL, causing a segfault later on.
    
    Reported-By: Peter Czanik <peter.czanik at balabit.hu>
    Signed-off-by: Balazs Scheidler <bazsi at balabit.hu>



-- 
Bazsi