Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG  Not logged in ELOG logo
icon4.gif   crash with attachment with very long filename, posted by Stefano Lacaprara on Fri Mar 25 10:07:37 2022 
    icon2.gif   Re: crash with attachment with very long filename, posted by Stefan Ritt on Mon Mar 28 14:04:18 2022 
       icon2.gif   Re: crash with attachment with very long filename, posted by Stefano Lacaprara on Tue Mar 29 11:31:55 2022 
Message ID: 69501     Entry time: Mon Mar 28 14:04:18 2022     In reply to: 69500     Reply to this: 69502
Icon: Reply  Author: Stefan Ritt  Author Email: stefan.ritt@psi.ch 
Category: Bug report  OS: Linux  ELOG Version: elogd 3.1.4  
Subject: Re: crash with attachment with very long filename 
Hi Stefano,

well, why in heaven's name do you run 200+ chars file names? I see that they are generated probably automatically, but I guess you will run in all kinds of other problems in doing that.

I had a check with elogd. I found one buffer overflow once you delete an attachment with a long file name. I fixed that and committed the change.

Concerning your crash, I was not able to reproduce it. Used a 255 char long filename, and could NOT crash elogd. Maybe you have an oder version or some special config options which
trigger that crash. Try with the newest git version and a minimal elogd.cfg configuration. Please also add line numbers during compilation (-g -o0 flags) so that I can better analyze
your backtrace. Best would be if I could reproduce your error.

Best,
Stefan



> Hi,
>   I'm running 
> elogd 3.1.4 built Jan 27 2021, 09:56:34 revision 395e101a
> on an ubuntu server.
> 
> I have a crash when very long filename (200 chars) are attached to an logbook entry.
> 
> The uploading of the attachment works almost fine: the filename is truncated and the convert to thumbnail is not working (as a consequence, maybe) but the file is actually uploaded and can be 
> downloaded correctly from the entry itself.
> 
> However, if I try to access the logbook list which contains that entry, I have a crash:
> 
> *** buffer overflow detected ***: terminated
> Aborted (core dumped)
> 
> [backtrace is attached below]
> 
> The only way I found to solve this is to edit manually the log entry and delete the attachment from it.
> 
> Any suggestion how to solve this?
> 
> Thanks
>   Stefano
> 
> 
> *** buffer overflow detected ***: terminated
> 
> Program received signal SIGABRT, Aborted.
> __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
> 50	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> (gdb) bp
> Undefined command: "bp".  Try "help".
> (gdb) backtrace 
> #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
> #1  0x00007ffff7cf4859 in __GI_abort () at abort.c:79
> #2  0x00007ffff7d5f29e in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff7e8908f "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:155
> #3  0x00007ffff7e01aea in __GI___fortify_fail (msg=msg@entry=0x7ffff7e89025 "buffer overflow detected") at fortify_fail.c:26
> #4  0x00007ffff7e00386 in __GI___chk_fail () at chk_fail.c:28
> #5  0x00007ffff7d5707f in _IO_str_chk_overflow (fp=<optimized out>, c=<optimized out>) at iovsprintf.c:35
> #6  0x00007ffff7d64054 in __GI__IO_default_xsputn (n=<optimized out>, data=<optimized out>, f=<optimized out>) at libioP.h:948
> #7  __GI__IO_default_xsputn (f=0x7ffffff36ca0, data=<optimized out>, n=241) at genops.c:370
> #8  0x00007ffff7d4912c in __vfprintf_internal (s=s@entry=0x7ffffff36ca0, format=format@entry=0x555555622e74 "../%s/%s/%s", ap=ap@entry=0x7ffffff36de0, mode_flags=mode_flags@entry=6)
>     at ../libio/libioP.h:948
> #9  0x00007ffff7d57129 in __vsprintf_internal (
>     string=0x7ffffff37120 
> "../DAQ/220325_090630/j5K1OSy8XN9FRPriaBGOmMg3bih07CQKo68Sw6dskclxdOqKaTOsf2bX8UugSWn0s8zaAHe6VWiPcQVnmD8PM1tbQoVMr08dBrXKU2X2tBR4pJ3hlfxbKjspmcbiDTMy32eHIp6lFAVA9lppShmpiut4g4CtgDK3F2bOPzgzXEjPw
> W0SJWG"..., maxlen=<optimized out>, format=0x555555622e74 "../%s/%s/%s", args=args@entry=0x7ffffff36de0, mode_flags=6) at iovsprintf.c:95
> #10 0x00007ffff7dffe7b in ___sprintf_chk (s=<optimized out>, flag=<optimized out>, slen=<optimized out>, format=<optimized out>) at sprintf_chk.c:40
> #11 0x00005555555a939d in display_line ()
> #12 0x00005555555ddc8a in show_elog_list ()
> #13 0x00005555556010cf in interprete ()
> #14 0x0000555555601a33 in decode_get ()
> #15 0x000055555560461f in process_http_request ()
> #16 0x0000555555607745 in server_loop ()
> #17 0x000055555555a92c in main ()
ELOG V3.1.5-3fb85fa6