Bug #2096: fastcgi incomplete header might crash lighty - Lighttpd - lighty labs

Bug #2096

fastcgi incomplete header might crash lighty

Added by nitrox over 3 years ago. Updated over 3 years ago.

Status:

Fixed

Start date:

2009-11-07

Priority:

Normal

Due date:

Assignee:

% Done:

100%

Category:

mod_fastcgi

Target version:

1.4.25

Missing in 1.5.x:

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 over 3 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 over 3 years ago

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

Applied in changeset r2692.

#2 Updated by stbuehler over 3 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

Lighttpd