[CRITICAL] uninitialized response field can sometimes cause crashes

The response message in the transaction structure was not properly
initialised at session initialisation. In theory it cannot cause any
trouble since the affected field os expected to always remain NULL.
However, in some circumstances, such as building on 64-bit platforms
with certain options, the struct session can be exactly 1024 bytes,
the same size of the requri field, so the pools are merged and the
uninitialised field may contain non-null data, causing crashes if
an invalid response is encountered and archived.

The fix simply consists in correctly initialising the missing fields.
This bug cannot affect architectures where the session pool is not
shared (32-bit architectures), but this is only by pure luck.

diff --git a/src/client.c b/src/client.c
index b3e19804d5264a213c00dc275a29cd8fe3668c9a..eb61da5eccd187ef99bf61b68a725a5be9234e08 100644 (file)
--- a/src/client.c
+++ b/src/client.c
@@ -266,6 +266,8 @@ int event_accept(int fd) {
                        txn->rsp.msg_state = HTTP_MSG_RPBEFORE; /* at the very beginning of the response */
                        txn->req.sol = txn->req.eol = NULL;
                        txn->req.som = txn->req.eoh = 0; /* relative to the buffer */
+                       txn->rsp.sol = txn->rsp.eol = NULL;
+                       txn->rsp.som = txn->rsp.eoh = 0; /* relative to the buffer */
                        txn->req.err_pos = txn->rsp.err_pos = -2; /* block buggy requests/responses */
                        if (p->options2 & PR_O2_REQBUG_OK)
                                txn->req.err_pos = -1; /* let buggy requests pass */