httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ef-li...@email.de
Subject Crash in Apache Core
Date Tue, 10 Nov 2009 10:53:55 GMT
Hi folks,

I think I found a bug in either the Apache core or mod_proxy_fcgi otherwise.

First, let me describe my scenario:

I run Apache 2.2.14 on a Debian (2.6.28-2-amd64) box. As I have a urgent need for mod_proxy_fcgi,
I tried a "backport" by copying mod_proxy_fcgi.c and fcgi_protocol.h to modules/proxy from
the current Apache trunk, modified the Makefile.am, ran buildconf and so on - everything's
fine. mod_proxy_fcgi seems to work out of the box without any source-changes. By the way -
it would be really great to have mod_proxy_fcgi in 2.2. As mod_proxy_scgi did it, I hope mod_proxy_fcgi
will come soon? :)

For your reference, this is my configure line:
./configure --with-mpm=worker --enable-maintainer-mode --enable-exception-hook --enable-so
--enable-proxy --enable-proxy-fcgi
I added --enable-maintainer-mode --enable-exception-hook to aid me in debugging. The scenario
crashes with and without these options.


Now if my FCGI-backend sends an invalid header in a response, Apache segfaults. This is the
stack trace:
#0  0x0000000000ad9630 in ?? ()
#1  0x000000000044b2d3 in getsfunc_BRIGADE (buf=0x4cf85a20 "<html>", len=8191, arg=0xae1ee0)
at util_script.c:636
#2  0x000000000044af2a in ap_scan_script_header_err_core (r=0xadb6e8, buffer=0x0, getsfunc=0x44b267
<getsfunc_BRIGADE>, getsfunc_data=0xae1ee0) at util_script.c:540
#3  0x000000000044b465 in ap_scan_script_header_err_brigade (r=0xadb6e8, bb=0xae1ee0, buffer=0x0)
at util_script.c:669
#4  0x0000000000478e87 in handle_headers (r=0xadb6e8, state=0x4cf89b7c,
    readbuf=0x4cf87b40 "200 OK\r\nContent-Type: text/html;\r\nSet-Cookie: TestCookie=\"FCGI
TestCookie\"; Comment=\"Test-Cookie ueber FCGI\"; Path=/; Version=1;\r\n\r\n<html>\n",
ob=0xae1ee0)
    at mod_proxy_fcgi.c:479
#5  0x00000000004795c6 in dispatch (conn=0xa49b58, r=0xadb6e8, request_id=1) at mod_proxy_fcgi.c:750
#6  0x0000000000479909 in fcgi_do_request (p=0xadb668, r=0xadb6e8, conn=0xa49b58, origin=0x0,
conf=0xa73600, uri=0xae0db8, url=0xae0e40 "/hallo", server_portstr=0x4cf89d30 ":8080") at
mod_proxy_fcgi.c:890
#7  0x0000000000479c79 in proxy_fcgi_handler (r=0xadb6e8, worker=0xa77f78, conf=0xa73148,
url=0xae0e40 "/hallo", proxyname=0x0, proxyport=0) at mod_proxy_fcgi.c:981
#8  0x00000000004676a4 in proxy_run_scheme_handler (r=0xadb6e8, worker=0xa77f78, conf=0xa73148,
url=0xae0cde "fcgi://proto-web1:80/hallo", proxyhost=0x0, proxyport=0) at mod_proxy.c:2380
#9  0x0000000000463d7a in proxy_handler (r=0xadb6e8) at mod_proxy.c:996
#10 0x0000000000443508 in ap_run_handler (r=0xadb6e8) at config.c:158
#11 0x0000000000443da1 in ap_invoke_handler (r=0xadb6e8) at config.c:372
#12 0x00000000004861bc in ap_process_request (r=0xadb6e8) at http_request.c:282
#13 0x0000000000483194 in ap_process_http_connection (c=0xad57b0) at http_core.c:190
#14 0x000000000044c94a in ap_run_process_connection (c=0xad57b0) at connection.c:43
#15 0x000000000044cd78 in ap_process_connection (c=0xad57b0, csd=0xad5598) at connection.c:178
#16 0x00000000004a0e52 in process_socket (p=0xad5518, sock=0xad5598, my_child_num=0, my_thread_num=23,
bucket_alloc=0xad9658) at worker.c:544
#17 0x00000000004a1728 in worker_thread (thd=0xa78e50, dummy=0xa389c0) at worker.c:894
#18 0x00007f7d0bf7befd in dummy_worker (opaque=0xa78e50) at threadproc/unix/thread.c:142
#19 0x00007f7d0b8fcfc7 in start_thread () from /lib/libpthread.so.0
#20 0x00007f7d0b46e5ad in clone () from /lib/libc.so.6
#21 0x0000000000000000 in ?? ()

While eating up the response in getsfunc_BRIGADE, apr_bucket_read hits the brigade sentinel
(the (e)->type->read pointer of a sentinel is obviously bogus) and segfaults.

I can't judge if mod_proxy_fcgi doesn't meet the preconditions to call ap_scan_script_header_err_brigade
or getsfunc_BRIGADE should be prepared to see brigade sentinels. But anyway, crashing Apache
with a bad response isn't a good thing at all.

While I understand that a fix will need some time, what would be your suggestion for a workaround
with proper handling?

Regards,
Edgar Frank

Mime
View raw message