[Bug 63398] New: mod_ssl/mod_cluster segfault with httpd 2.4.39 but did not happen on previous version

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[Bug 63398] New: mod_ssl/mod_cluster segfault with httpd 2.4.39 but did not happen on previous version

Bugzilla from bugzilla@apache.org
https://bz.apache.org/bugzilla/show_bug.cgi?id=63398

            Bug ID: 63398
           Summary: mod_ssl/mod_cluster segfault with httpd 2.4.39 but did
                    not happen on previous version
           Product: Apache httpd-2
           Version: 2.4.39
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: mod_ssl
          Assignee: [hidden email]
          Reporter: [hidden email]
  Target Milestone: ---

After updating RPM in Fedora 29, the Apache instance with mod_ssl and
mod_cluster would segfault but no core dump is produced.
Previous working version: Apache 2.4.37 , mod_cluster 1.3.3.

After updating to version: Apache 2.4.39, no changes to mod_cluster, httpd
segfaults.

Downstream is Fedora 29. I had opened ticket
https://bugzilla.redhat.com/show_bug.cgi?id=1705574 , they said it is
mod_cluster problem, not mod_ssl problem. I want to get a second opinion from
Apache, thanks.

I am using this config for 443 SSL virtual host and mod_cluster management port
ProxyRequests Off
ProxyVia On
ProxyPreserveHost On
RequestHeader set Front-End-Https "On"
SSLProxyEngine on
SSLProxyCACertificateFile "/etc/cacert.crt"
SSLProxyCheckPeerName off
SSLProxyCheckPeerCN off

Kernel:
segfault at 298 ip 00007f2d5afb2957 sp 00007f2d587c1a48 error 4 in
mod_ssl.so[7f2d5af94000+22000]

Apache log:
[Fri May 03 15:38:22.352296 2019] [core:notice] [pid 3043] AH00052: child pid
3366 exit signal Segmentation fault (11)

gdb back trace:

(gdb) c
Continuing.
[Attaching after Thread 0x7f94bcfdc900 (LWP 3043) fork to child process 3396]
[New inferior 2 (process 3396)]
[Detaching after fork from parent process 3043]
[Inferior 1 (process 3043) detached]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7f94bae18700 (LWP 3397)]
[New Thread 0x7f94b9b76700 (LWP 3398)]
[New Thread 0x7f94b9375700 (LWP 3399)]
[New Thread 0x7f94b8b74700 (LWP 3400)]
[New Thread 0x7f94b3fff700 (LWP 3401)]
[New Thread 0x7f94b37fe700 (LWP 3402)]
[New Thread 0x7f94b2ffd700 (LWP 3403)]
[New Thread 0x7f94b27fc700 (LWP 3404)]
[New Thread 0x7f94b1ffb700 (LWP 3405)]
[New Thread 0x7f94b17fa700 (LWP 3406)]
[New Thread 0x7f94b0ff9700 (LWP 3407)]
[New Thread 0x7f94b07f8700 (LWP 3408)]
[New Thread 0x7f94afff7700 (LWP 3409)]
[New Thread 0x7f94af7f6700 (LWP 3410)]
[New Thread 0x7f94aeff5700 (LWP 3411)]
[New Thread 0x7f94ae7f4700 (LWP 3412)]
[New Thread 0x7f94adff3700 (LWP 3413)]
[New Thread 0x7f94ad7f2700 (LWP 3414)]

Thread 2.4 "httpd" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f94b9375700 (LWP 3399)]
0x00007f94bcaec957 in modssl_request_is_tls (r=0x56128cfc22b0,
scout=scout@entry=0x0) at ssl_util.c:105
105     ssl_util.c: No such file or directory.
(gdb) backtrace full
#0  0x00007f94bcaec957 in modssl_request_is_tls (r=0x56128cfc22b0,
scout=scout@entry=0x0) at ssl_util.c:105
        sslconn = <optimized out>
        sc = <optimized out>
#1  0x00007f94bcad24ef in ssl_hook_default_port (r=<optimized out>) at
mod_ssl.c:633
No locals.
#2  0x000056128c760458 in ap_run_default_port (r=0x56128cfc22b0) at
protocol.c:2441
        pHook = <optimized out>
        n = 0
        rv = 0
#3  0x000056128c7673bb in ap_get_server_port (r=r@entry=0x56128cfc22b0) at
core.c:1186
        port = 0
        d = <optimized out>
#4  0x00007f94bcbd4f91 in ap_proxy_determine_connection (p=0x56128cfc2238,
r=r@entry=0x56128cfc22b0, conf=conf@entry=0x56128ceb0b08,
    worker=worker@entry=0x56128ceb3758, conn=0x56128cf97a10,
uri=uri@entry=0x56128cfc2990, url=0x7f94b9374b58, proxyname=0x0, proxyport=0,
    server_portstr=0x7f94b9374b60 "", server_portstr_size=32) at
proxy_util.c:2533
        server_port = <optimized out>
        err = <optimized out>
        uerr = <optimized out>
        uds_path = <optimized out>
#5  0x00007f94bc32eafa in proxy_cluster_try_pingpong (r=r@entry=0x56128cfc22b0,
worker=worker@entry=0x56128ceb3758,
    url=url@entry=0x56128ced8c30
"https://my-internal-ip-address-redacted:8597/",
conf=conf@entry=0x56128ceb0b08, workertimeout=<optimized out>,
    ping=<optimized out>) at mod_proxy_cluster.c:1333
        status = 0
        timeout = <optimized out>
        backend = 0x56128cf97a10
        server_portstr =
"\000\210\355\214\022V\000\000\b\362\247\274\224\177\000\000\255\026\063\274\224\177\000\000P(\374\214\022V\000"
        locurl = 0x56128cfc2a28 "/"
        uri = 0x56128cfc2990
        scheme = 0x7f94bca7f208 "https"
        is_ssl = <optimized out>
#6  0x00007f94bc32f82a in update_workers_lbstatus (server=0x56128ce53d20,
pool=<optimized out>, conf=<optimized out>)
--Type <RET> for more, q to quit, c to continue without paging--
    at mod_proxy_cluster.c:1543
        url = <optimized out>
        rv = <optimized out>
        rnew = <optimized out>
        worker = <optimized out>
        sport = ":8597\000"
        rrp = 0x56128cfc2238
        elected = <optimized out>
        oldelected = <optimized out>
        stat = <optimized out>
        ptr = <optimized out>
        ou = 0x7f94bca7f068
        id = <optimized out>
        size = <optimized out>
        i = <optimized out>
        now = 1556869107165344
        id = <optimized out>
        size = <optimized out>
        i = <optimized out>
        now = <optimized out>
        ou = <optimized out>
        elected = <optimized out>
        oldelected = <optimized out>
        stat = <optimized out>
        ptr = <optimized out>
        sport = <optimized out>
        url = <optimized out>
        rv = <optimized out>
        rrp = <optimized out>
        rnew = <optimized out>
        worker = <optimized out>
--Type <RET> for more, q to quit, c to continue without paging--
#7  proxy_cluster_watchdog_func (thd=<optimized out>, data=<optimized out>) at
mod_proxy_cluster.c:2636
        s = 0x56128ce53d20
        sconf = <optimized out>
        conf = <optimized out>
        last = <optimized out>
        rv = <optimized out>
        pool = 0x56128ced88c8
#8  0x00007f94bd4ab58e in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#9  0x00007f94bd3d4683 in clone () from /lib64/libc.so.6
No symbol table info available.
(gdb) info locals
sslconn = <optimized out>
sc = <optimized out>

--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[Bug 63398] mod_ssl/mod_cluster segfault with httpd 2.4.39 but did not happen on previous version

Bugzilla from bugzilla@apache.org
https://bz.apache.org/bugzilla/show_bug.cgi?id=63398

Joe Orton <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|NEW                         |RESOLVED

--- Comment #1 from Joe Orton <[hidden email]> ---
Second opinion = first opinion.  mod_cluster makes "fake" conn_rec/request_rec
structures which is highly likely to break across patch updates to httpd.  In
this case mod_ssl is using conn_rec in a perfectly valid way according to the
httpd API, but mod_cluster does not fake enough of that API to maintain
compatibility.

I would recommend tying modules like this to an httpd minor version known to be
compatible at build time.

--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]