BUG/MAJOR: possible crash when using capture headers on TCP frontends

Olufemi Omojola provided a config and a core showing a possible crash
when captures are configured on a TCP-mode frontend which branches to
an HTTP backend. The reason is that being in TCP mode, the frontend
does not allocate capture pools for the request, but the HTTP backend
tries to use them and dies on the NULL.

While such a config has long been unlikely to happen, it looks like
people using websocket tend to do this more often now.

Change the control to use the pointer instead of the number of captures
to know when to log.

This bug was reported in 1.4.20, so it must be backported there.
This commit is contained in:
Willy Tarreau 2012-03-24 08:28:09 +01:00
parent 7f25debbd2
commit 42f7d89156

View File

@ -2416,7 +2416,7 @@ int http_wait_for_request(struct session *s, struct buffer *req, int an_bit)
txn->flags &= ~TX_REQ_XFER_LEN;
/* 5: we may need to capture headers */
if (unlikely((s->logs.logwait & LW_REQHDR) && s->fe->req_cap))
if (unlikely((s->logs.logwait & LW_REQHDR) && txn->req.cap))
capture_headers(msg->sol, &txn->hdr_idx,
txn->req.cap, s->fe->req_cap);
@ -4672,7 +4672,7 @@ int http_wait_for_response(struct session *s, struct buffer *rep, int an_bit)
* 3: we may need to capture headers
*/
s->logs.logwait &= ~LW_RESP;
if (unlikely((s->logs.logwait & LW_RSPHDR) && s->fe->rsp_cap))
if (unlikely((s->logs.logwait & LW_RSPHDR) && txn->rsp.cap))
capture_headers(msg->sol, &txn->hdr_idx,
txn->rsp.cap, s->fe->rsp_cap);