https://bz.apache.org/bugzilla/show_bug.cgi?id=63503

            Bug ID: 63503
           Summary: Reverse proxy server - SIGSEGV
           Product: Apache httpd-2
           Version: 2.4.39
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: major
          Priority: P2
         Component: mod_proxy
          Assignee: [email protected]
          Reporter: [email protected]
  Target Milestone: ---

Created attachment 36627
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=36627&action=edit
Output of 'diff -u old new'

Hello. Recently, we ran a stress test (using Loadrunner) against our backend
server using Apache as a reverse-proxy server. We've been running this way for
some years. It's not clear when the last time (or if ever) this stress test was
run, but we noticed that we were getting SegVs in various locations (mainly in
mod_proxy). We're running version 2.4.39 of httpd and version 1.7.0 of APR on
RHEL 7.6. We're also using worker mpm and if we switch to the event or prefork
mpms, we don't get any errors. Our program also runs on AIX where the event mpm
isn't available, so we needed a fix. We haven't actually run the test on AIX,
just Linux. We were able to reproduce the problem at 2.4.38 and 2.4.34 and
didn't try any other versions.

Looking at the core files, we could see corrupted memory chains and sometimes
we see a pointer to thread_mutex_cleanup(). Since this pointer is only
referenced in the code as an argument to apr_pool_cleanup_register(), this led
us to believe that we were seeing a case where two threads were accessing the
same pool concurrently. We rebuilt httpd using --enable-pool-concurrency-check
and the SegVs turned into aborts emitted by the pool concurrency check.

Looking at these new core files, it could be seen that two threads were
concurrently accessing the same worker proxy connection pool. While
proxy_util.c has one mutex call around the call to apr_sockaddr_info_get()
(where the proxy connection pool is used), there were other calls in this
module that needed the same protection.

I found some previous bug reports that might be due to this same issue:

https://bz.apache.org/bugzilla/show_bug.cgi?id=58491
https://bz.apache.org/bugzilla/show_bug.cgi?id=58529
https://bz.apache.org/bugzilla/show_bug.cgi?id=62357

We've coded a fix and I'll attach the patch. I applied our change to the top of
the tree with the same changes I've tested at 2.4.39. I left the APLOGNO()
empty. i.e. I have run the update-log-msg-tags perl script. Let me know if
there are questions or concerns. Thanks.

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

Reply via email to