Bug #2096

fastcgi incomplete header might crash lighty

Added by nitrox about 5 years ago. Updated about 5 years ago.

Status:FixedStart date:2009-11-07
Priority:NormalDue date:
Assignee:-% Done:

100%

Category:mod_fastcgi
Target version:1.4.25
Missing in 1.5.x:No

Description

bt full said:

#0  fcgi_write_request (srv=0x604800, hctx=0x7781f0) at mod_fastcgi.c:2112

Line 2112 at mod_fastcgi.c is: switch (req_c->type)

Backtrace from gdb showed null-pointer dereference:

(gdb) p con
$1 = (connection *) 0x64e800
(gdb) p con->request_content_queue
$2 = (chunkqueue *) 0x6c3840
(gdb) p con->request_content_queue->first
$3 = (chunk *) 0x0

Quick fix was:

Index: src/mod_fastcgi.c
===================================================================
--- src/mod_fastcgi.c   (Revision 2639)
+++ src/mod_fastcgi.c   (copy)
 -2079,7 +2079,7 @@
        b->used++; /* add virtual \0 */
        hctx->wb->bytes_in += b->used - 1;

-       if (con->request.content_length) {
+       if (con->request.content_length && con->request_content_queue->first) {
                chunkqueue *req_cq = con->request_content_queue;
                chunk *req_c;
                off_t offset;

Associated revisions

Revision 2692
Added by stbuehler about 5 years ago

mod_fastcgi: Don't reconnect after connect() succeeded (fixes #2096)

- a reconnect would try to rebuild the outgoing queue,
which involves reusing the post body - but the first
try already removed it.
we could try reusing the queue, but otoh that really
isn't our problem. accept() it - handle it.

History

#1 Updated by stbuehler about 5 years ago

  • Status changed from New to Fixed
  • % Done changed from 0 to 100

Applied in changeset r2692.

#2 Updated by stbuehler about 5 years ago

Additional comment:
This segfault is triggered when the fastcgi applications closes the connection while lighty starts pushing data to fastcgi (i.e. nothing written yet) and the write backend returns ENOTCONN. And of course you need a http-body, i.e. request content-length > 0.
I couldn't trigger this on linux, writev() always returned EPIPE for "fast-closed" unix sockets and with tcp the first write never failed (bug was reported on FreeBSD).

Also available in: Atom