Project

General

Profile

Actions

Bug #2096

closed

fastcgi incomplete header might crash lighty

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

Status:
Fixed
Priority:
Normal
Category:
mod_fastcgi
Target version:
ASK QUESTIONS IN Forums:

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;

Actions #1

Updated by stbuehler over 14 years ago

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

Applied in changeset r2692.

Actions #2

Updated by stbuehler over 14 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).

Actions

Also available in: Atom