Bug #2984


Segmentation fault in mod_extforward with libmusl

Added by rei-de-barulho over 4 years ago. Updated over 4 years ago.

Target version:


Version: 1.4.54.

Steps to reproduce:
  1. Configure mod_extforward to trust all hosts:
    extforward.headers = ("X-Forwarded-For", "X-Forwarded-Proto")
    extforward.forwarder = ("all" => "trust")
  2. Send the following HTTP request
    GET / HTTP/1.1
    X-Forwarded-For: b:2

Expected result: server will continue work.

Actual result: segmentation fault. Server does not continue serving requests after the crash.

Additional info: libmusl is used unstead of GLIBC.

Actions #1

Updated by rei-de-barulho over 4 years ago

The issue cannot be reproduced on GLIBC-based systems.

Actions #2

Updated by gstrauss over 4 years ago

What architecture are you on? x86? x86_64? ARM 32-bit? ARM 64-bit? other?
Have you, by chance, tested this on any other architectures?

Do you have a stack trace?

If not, would you please set debug.log-request-handling = "enable" in your lighttpd.conf and share what is in the log immediately prior to the crash?

Actions #3

Updated by byrn over 4 years ago

I tested this issue on a fresh Alpine Linux x86_64 VM with lighttpd/1.4.54 (ssl). Here is the result of the error.log with log-request-handling enabled :

2019-09-26 18:33:58: (server.c.1521) server started (lighttpd/1.4.54) 
2019-09-26 18:34:05: (response.c.435) -- splitting Request-URI 
2019-09-26 18:34:05: (response.c.436) Request-URI     :  / 
2019-09-26 18:34:05: (response.c.437) URI-scheme      :  http 
2019-09-26 18:34:05: (response.c.438) URI-authority   : 
2019-09-26 18:34:05: (response.c.439) URI-path (raw)  :  / 
2019-09-26 18:34:05: (response.c.440) URI-path (clean):  / 
2019-09-26 18:34:05: (response.c.441) URI-query       :   
2019-09-26 18:34:05: (mod_extforward.c.1014) -- mod_extforward_uri_handler called 
2019-09-26 18:34:05: (mod_extforward.c.514) using address: b:2 
2019-09-26 18:34:05: (sock_addr.c.595) could not parse ip address b:2 because Name does not resolve (Invalid argument)
Actions #4

Updated by rei-de-barulho over 4 years ago

I start lighttpd on x84_64.

Stack trace:

#0  0x00007ffff7fa34fb in freeaddrinfo (p=0x0) at src/network/freeaddrinfo.c:10
#1  0x000055555558327e in sock_addr_from_str_numeric (srv=srv@entry=0x7ffff7c88ca0, saddr=saddr@entry=0x7fffffffe908, str=str@entry=0x5555556502e0 "b:2")
    at sock_addr.c:620
#2  0x00007ffff7c4503e in mod_extforward_set_addr (srv=srv@entry=0x7ffff7c88ca0, con=con@entry=0x5555555cd4a0, addr=addr@entry=0x5555556502e0 "b:2", p=<optimized out>)
    at mod_extforward.c:518
#3  0x00007ffff7c466f2 in mod_extforward_X_Forwarded_For (x_forwarded_for=<optimized out>, p=0x5555555b8400, con=0x5555555cd4a0, srv=0x7ffff7c88ca0)
    at mod_extforward.c:597
#4  mod_extforward_uri_handler (srv=0x7ffff7c88ca0, con=0x5555555cd4a0, p_d=0x5555555b8400) at mod_extforward.c:1068
#5  0x0000555555579b35 in plugins_call_handle_uri_raw (srv=srv@entry=0x7ffff7c88ca0, con=con@entry=0x5555555cd4a0) at plugin.c:314
#6  0x000055555556a1e2 in http_response_prepare (srv=srv@entry=0x7ffff7c88ca0, con=con@entry=0x5555555cd4a0) at response.c:469
#7  0x000055555556bf0d in connection_handle_request (con=0x5555555cd4a0, srv=0x7ffff7c88ca0) at connections.c:1272
#8  connection_state_machine (srv=srv@entry=0x7ffff7c88ca0, con=0x5555555cd4a0) at connections.c:1272
#9  0x000055555556cb7a in network_server_handle_fdevent (srv=0x7ffff7c88ca0, context=0x5555555b8740, revents=<optimized out>) at network.c:65
#10 0x000055555557c758 in fdevent_linux_sysepoll_poll (ev=0x5555555c7be0, timeout_ms=<optimized out>) at fdevent_linux_sysepoll.c:44
#11 0x0000555555573099 in fdevent_poll (ev=0x5555555c7be0, timeout_ms=<optimized out>) at fdevent.c:397
#12 0x00005555555691d6 in server_main_loop (srv=0x7ffff7c88ca0) at server.c:2040
#13 0x0000555555560e4d in main (argc=4, argv=0x7fffffffec68) at server.c:2081

Actions #5

Updated by rei-de-barulho over 4 years ago

I think there is a problem in libmusl. Its freeaddrinfo() function does not have a nullptr-check:

Actions #6

Updated by gstrauss over 4 years ago

It does sound like a problem with freeaddrinfo(). This (untested) patch might help you work around it in lighttpd:

--- a/src/sock_addr.c
+++ b/src/sock_addr.c
@@ -594,11 +594,12 @@ int sock_addr_from_str_numeric(server *srv, sock_addr *saddr, const char *str)
         log_error_write(srv, __FILE__, __LINE__, "SSSs(S)",
                         "could not parse ip address ", str, " because ",
                         gai_strerror(result), strerror(errno));
+        return result;
     } else if (addrlist == NULL) {
         log_error_write(srv, __FILE__, __LINE__, "SSS",
                         "Problem in parsing ip address ", str,
                         ": succeeded, but no information returned");
-        result = -1;
+        return -1;
     } else switch (addrlist->ai_family) {
     case AF_INET:
         memcpy(&saddr->ipv4, addrlist->ai_addr, sizeof(saddr->ipv4));

Actions #7

Updated by gstrauss over 4 years ago

  • Subject changed from Segmentation fault in mod_extforward to Segmentation fault in mod_extforward with libmusl
  • Status changed from New to Patch Pending
  • Target version changed from 1.4.x to 1.4.55
Actions #8

Updated by gstrauss over 4 years ago

  • Status changed from Patch Pending to Fixed
  • % Done changed from 0 to 100

Also available in: Atom