Actions
Bug #2096
closedfastcgi incomplete header might crash lighty
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;
Updated by stbuehler about 15 years ago
- Status changed from New to Fixed
- % Done changed from 0 to 100
Applied in changeset r2692.
Updated by stbuehler about 15 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