Bug #3099
closedSIGSEGV in early SSL_read() API call (misconfigured lighttpd.conf)
Description
Lighttpd crashes if an API call is performed relatively fast after a reboot.
If I do the same API calls a bit later, then I don't see those crashes.
I can't tell you the exact reproduction steps, but I discovered them while doing reboot tests.
This is a regression that I saw while rebasing Buildroot from 2020.02.7 to 2021.02.4.
lighttpd 1.4.55 --> 1.4.58
I also tested version 1.4.59 to be sure that https://redmine.lighttpd.net/issues/3052 isn't applicable.
Used SSL libs:
libressl 3.2.5 --> 3.2.5 (same version)
libopenssl 1.1.1g --> 1.1.1k
Strace output:
accept4(5<socket:[5859]>, {sa_family=AF_INET, sin_port=htons(56950), sin_addr=inet_addr("<ip>")}, [112->16], SOCK_CLOEXEC|SOCK_NONBLOCK) = 8<socket:[11907]>
gettimeofday({tv_sec=1630501034, tv_usec=205162}, NULL) = 0
read(8<socket:[11907]>, "<data>", 5) = 5
read(8<socket:[11907]>, "<data>"..., 183) = 183
gettimeofday({tv_sec=1630501034, tv_usec=206804}, NULL) = 0
write(8<socket:[11907]>, "<data>"..., 1277) = 1277
read(8<socket:[11907]>, 0xc76bb, 5) = -1 EAGAIN (Resource temporarily unavailable)
epoll_ctl(7<anon_inode:[eventpoll]>, EPOLL_CTL_ADD, 8<socket:[11907]>, {EPOLLIN|EPOLLERR|EPOLLHUP|EPOLLRDHUP, {u32=729704, u64=850296151155304}}) = 0
accept4(5<socket:[5859]>, 0xbed53bd8, [112], SOCK_CLOEXEC|SOCK_NONBLOCK) = -1 EAGAIN (Resource temporarily unavailable)
gettimeofday({tv_sec=1630501034, tv_usec=344363}, NULL) = 0
epoll_wait(7<anon_inode:[eventpoll]>, [{EPOLLIN, {u32=729704, u64=850296151155304}}], 1025, 1000) = 1
read(8<socket:[11907]>, "<data>", 5) = 5
read(8<socket:[11907]>, "<data>"..., 102) = 102
read(8<socket:[11907]>, "<data>", 5) = 5
read(8<socket:[11907]>, "<data>", 1) = 1
read(8<socket:[11907]>, "<data>", 5) = 5
read(8<socket:[11907]>, "<data>"..., 40) = 40
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x10} ---
+++ killed by SIGSEGV +++
mna-240-2530066145 # client_loop: send disconnect: Broken pipe
Adding some logs learned me that it goes wrong in an SSL_read call:
https://git.lighttpd.net/lighttpd/lighttpd1.4/src/tag/lighttpd-1.4.58/src/mod_openssl.c#L2950
Let me know where I can help.
Updated by gstrauss over 3 years ago
- Has duplicate Bug #3098: SIGSEGV in early SSL_read() API call (misconfigured lighttpd.conf) added
Updated by gstrauss over 3 years ago
- Subject changed from SIGSEGV in early API call to SIGSEGV in early SSL_read() API call (misconfigured lighttpd.conf)
- Category deleted (
core) - Status changed from New to Invalid
A stack trace at the point of the crash would be useful.
Have you configured the buildroot to save core files when a program crashes?
Since you said the crash occurs in SSL_read(), you might also install the debugging symbols for the openssl library, so that you can get better information in the core file from the stack trace.
.
Another alternative to test is using an alternative TLS library, such as mbedTLS with lighttpd mod_mbedtls, or wolfSSL with lighttpd mod_wolfssl.
.
All that said, based on your previous post (#3097), have you considered that there is a MUCH, MUCH higher probability that you are doing something wrong which causes the crash, than that there is a bug in a TLS library? Please see How to get support Notice that you have failed to provide critically important information such as your lighttpd.conf with lighttpd -f /etc/lighttpd/lighttpd.conf -p. A problem that occassionally comes up (which has a better warning in the upcoming lighttpd 1.4.60) is that you have misconfigured TLS in your lighttpd.conf by placing $SERVER["socket"] config in a nested condition. There are warnings in the lighttpd Configuration: File Syntax and in lighttpd TLS docs. See also #3096.
@ThomasDevoogdt:
Please do not make any further posts to the lighttpd issue tracker. Instead, please post in the lighttpd Forums
Before posting, please use the Search box in the upper right of this page to search lighttpd's Issues and Forums to see if your question was already asked and answered.
Updated by gstrauss over 3 years ago
To be helpful to others, please post where you found the incorrect lighttpd TLS syntax. If on stackoverflow, please post the link and I'll correct the poster.
Also available in: Atom