Thanks to your stack trace, I found a case where a string might get overwritten, but only if the attachment file name is longer than 256 chars. I fixed the code and made a new RPM:
https://www.dropbox.com/scl/fi/r37qx9aka5ytt3j7vn4km/elog-3.1.5-20241213.el8.x86_64.rpm?rlkey=knct99pdltggunrbmyr2hpfe5&st=pkre24aq&dl=0
Alternatively, you can compile from sources. Give it a try.
Stefan |
Thanks for further instructions here is full stack trace:
Program received signal SIGABRT, Aborted.
__pthread_kill_implementation (no_tid=0, signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:44
warning: 44 ./nptl/pthread_kill.c: No such file or directory
(gdb) where
#0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:44
#1 __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78
#2 __GI___pthread_kill (threadid=<optimized out>, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
#3 0x00007ffff764526e in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#4 0x00007ffff76288ff in __GI_abort () at ./stdlib/abort.c:79
#5 0x00007ffff76297b6 in __libc_message_impl (fmt=fmt@entry=0x7ffff77ce765 "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:132
#6 0x00007ffff7736c19 in __GI___fortify_fail (msg=msg@entry=0x7ffff77ce74c "buffer overflow detected") at ./debug/fortify_fail.c:24
#7 0x00007ffff77365d4 in __GI___chk_fail () at ./debug/chk_fail.c:28
#8 0x00007ffff7738019 in __strlcpy_chk (s1=<optimized out>, s2=<optimized out>, n=<optimized out>, s1len=<optimized out>) at ./debug/strlcpy_chk.c:28
#9 0x000055555557ac8a in strlcpy (__n=356, __src=0x89ab3c42edf52f00 <error: Cannot access memory at address 0x89ab3c42edf52f00>, __dest=0x7ffffffd5370 "agarcia") at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:156
#10 el_submit_attachment (lbs=lbs@entry=0x5555566873d8, afilename=afilename@entry=0x7ffffffd57e0 "pfSense-UDP4-1194-yuhaosun-config.ovpn",
buffer=buffer@entry=0x5555566bba67 "dev tun\npersist-tun\npersist-key\ndata-ciphers AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305:AES-256-CBC\ndata-ciphers-fallback AES-256-CBC\nauth SHA256\ntls-client\nclient\nresolv-retry infinite\nremote pfsense."...,
buffer_size=buffer_size@entry=5265, full_name=full_name@entry=0x7ffffffd58e0 "") at src/elogd.cxx:4547
#11 0x00005555555f91ea in decode_post (logbook=logbook@entry=0x7fffffffbff0 "He6", lbs=lbs@entry=0x5555566873d8, string=<optimized out>,
string@entry=0x5555566bb1c9 '-' <repeats 29 times>, "16417726823211458101306576170\r\nContent-Disposition: form-data; name=\"unm\"\r\n\r\ngholman\r\n", '-' <repeats 29 times>, "16417726823211458101306576170\r\nContent-Disposition: form"...,
boundary=boundary@entry=0x7fffffffbef0 '-' <repeats 27 times>, "16417726823211458101306576170", length=length@entry=7649) at src/elogd.cxx:28662
#12 0x00005555555fb5cc in process_http_request (
crequest=crequest@entry=0x555556656658 "POST /He6/ HTTP/1.0\r\nHost: xxx.xxx.xxx.xxx\r\nX-Real-IP: 192.168.101.2\r\nX-Forwarded-For: 192.168.101.2\r\nConnection: close\r\nContent-Length: 7649\r\nUser-Agent: Mozilla/5.0 (Windows NT 10.0; Win6"...,
i_conn=i_conn@entry=0) at src/elogd.cxx:29317
#13 0x00005555555ffc68 in server_loop () at src/elogd.cxx:30302
#14 0x000055555555b1b9 in main (argc=<optimized out>, argv=<optimized out>) at src/elogd.cxx:31327
(gdb)
| Stefan Ritt wrote: |
|
A statement like "core dumped" does not help much. Same with valgrind memory leaks. I need a full strack trace with all parameters when the segment violation occurs. The easiest is when you run elogd vom inside gdb, and once you get the signal, do a "where" to see th full stack trace.
As you can see from this forum, there is absolutely no crash when you upload any file, so it must have to do with your config file or anything whcih is special in yoru environment. We have to find what this is so that I can reproduce it here.
Stefan
|
|
A statement like "core dumped" does not help much. Same with valgrind memory leaks. I need a full strack trace with all parameters when the segment violation occurs. The easiest is when you run elogd vom inside gdb, and once you get the signal, do a "where" to see th full stack trace.
As you can see from this forum, there is absolutely no crash when you upload any file, so it must have to do with your config file or anything whcih is special in yoru environment. We have to find what this is so that I can reproduce it here.
Stefan |
I am receiving a segfault whenever I attempt to upload a file. Please see attached .txt for valgrind output. This occurs in version elog-3.1.5-1. I reverted back to version elog-3.1.4-3 and the segfault does not occur.
Segfault occurs in Elog version: elog-3.1.5-1
System:
Virtualization: kvm
Operating System: Ubuntu 24.04.1 LTS
Kernel: Linux 6.8.0-49-generic
Architecture: x86-64
Hardware Vendor: QEMU
Hardware Model: Standard PC _Q35 + ICH9, 2009_
Firmware Version: 1.15.0-1
Firmware Date: Tue 2014-04-01
Firmware Age: 10y 8month 1w 5d
Valgrind command: valgrind -v --leak-check=full --track-origins=yes ./elogd -s /usr/local/elog -c /var/www/elog/he6/elogd.cfg -f /var/run/elog/he6.pid
Steps to reproduce:
1. Login elog
2. Create new logbook entry
3. Attachement 1: Select Browse
4. Select any file.
5. Select Upload |