A little more info:
Program received signal SIGABRT, Aborted.
0x00007ffff69efcc9 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) backtrace
#0 0x00007ffff69efcc9 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007ffff69f30d8 in __GI_abort () at abort.c:89
#2 0x00007ffff6a2c394 in __libc_message (do_abort=do_abort@entry=2,
fmt=fmt@entry=0x7ffff6b3852b "*** %s ***: %s terminated\n") at
../sysdeps/posix/libc_fatal.c:175
#3 0x00007ffff6ac3c9c in __GI___fortify_fail (msg=<optimized out>,
msg@entry=0x7ffff6b384c2 "buffer overflow detected") at
fortify_fail.c:37
#4 0x00007ffff6ac2b60 in __GI___chk_fail () at chk_fail.c:28
#5 0x00007ffff63a02cd in memcpy (__len=18446744073709551615,
__src=<optimized out>, __dest=0x7fffffffd040)
at /usr/include/x86_64-linux-gnu/bits/string3.h:51
#6 checkInstance (inst=0x6b0210) at imfile.c:727
#7 0x00007ffff63a054d in newInpInst (lst=<optimized out>) at imfile.c:1066
#8 0x00000000004147a9 in inputProcessCnf (o=o@entry=0x6adc60) at
rsconf.c:354
#9 0x0000000000414ba0 in cnfDoObj (o=0x6adc60) at rsconf.c:427
#10 0x000000000045435e in yyparse () at grammar.y:129
#11 0x0000000000414145 in load (cnf=0x695cd0 <ourConf>, confFile=0x470309
"/etc/rsyslog.conf") at rsconf.c:1286
#12 0x0000000000448e2f in initAll (argc=argc@entry=1,
argv=argv@entry=0x7fffffffe688)
at rsyslogd.c:1252
#13 0x000000000040dfe0 in main (argc=1, argv=0x7fffffffe688) at
rsyslogd.c:1640
(gdb) frame 13
#13 0x000000000040dfe0 in main (argc=1, argv=0x7fffffffe688) at
rsyslogd.c:1640
1640 initAll(argc, argv);
(gdb) print argc
$1 = 1
(gdb) print argv
$2 = (char **) 0x7fffffffe688
On Thu, Mar 3, 2016 at 8:53 AM, Brian Knox <[email protected]> wrote:
> I've found a buffer overflow in imfile in the master-candidate branch. To
> reproduce, make an imfile config that uses a relative path rather than
> absolute to a file:
>
> ```
> module(load="imfile" PollingInterval="10")
>
> input(
> type="imfile"
> tag="crash"
> File="crashme"
> )
>
> *.* /var/log/syslog
> ```
>
> This results in:
>
> ```
> 3146.392981790:main thread : deletestateonfiledelete: (unset)
> 3146.392987727:main thread : addmetadata: (unset)
> 3146.392993638:main thread : addceetag: (unset)
> 3146.392999527:main thread : statefile: (unset)
> *** buffer overflow detected ***: rsyslogd terminated
> ======= Backtrace: =========
> /lib/x86_64-linux-gnu/libc.so.6(+0x7338f)[0x7f286982b38f]
> /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7f28698c2c9c]
> /lib/x86_64-linux-gnu/libc.so.6(+0x109b60)[0x7f28698c1b60]
> /usr/local/lib/rsyslog/imfile.so(+0x22cd)[0x7f286919f2cd]
> /usr/local/lib/rsyslog/imfile.so(+0x254d)[0x7f286919f54d]
> rsyslogd(inputProcessCnf+0x99)[0x4147a9]
> rsyslogd(cnfDoObj+0x90)[0x414ba0]
> rsyslogd(yyparse+0xbae)[0x45435e]
> rsyslogd(load+0xc35)[0x414145]
> rsyslogd(initAll+0x5ef)[0x448e2f]
> rsyslogd(main+0x30)[0x40dfe0]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f28697d9ec5]
> rsyslogd[0x40e35a]
> ```
>
> I don't have time to dig into it today but wanted to go ahead and report
> it. If I correctly use an absolute path to the file (I used a relative by
> mistake when testing and found this), things work as expected.
>
> If I get some time tomorrow to dig into it I will!
>
> Cheers,
> Brian
>
>
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE
THAT.
