ironbee/libhtp — pull request #64 by inliniac (2014-01-18 18:58:20+00:00)
Title: Fix memory leak in PUT requests

This patch addresses this valgrind warning seen in Suricata:

==31733== 280 bytes in 7 blocks are definitely lost in loss record 484 of 556
==31733== at 0x4C29DB4: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==31733== by 0x4E44A69: htp_tx_state_request_headers (htp_transaction.c:445)
==31733== by 0x4E409B4: htp_connp_REQ_HEADERS (htp_request.c:583)
==31733== by 0x4E40E09: htp_connp_req_data (htp_request.c:851)
==31733== by 0x436C4A: HTPHandleRequestData (app-layer-htp.c:723)
==31733== by 0x444BAD: AppLayerParserParse (app-layer-parser.c:780)
==31733== by 0x4161FA: AppLayerHandleTCPData (app-layer.c:266)
==31733== by 0x5B601F: StreamTcpReassembleAppLayer (stream-tcp-reassemble.c:3027)
==31733== by 0x5B68D4: StreamTcpReassembleHandleSegmentUpdateACK (stream-tcp-reassemble.c:3373)
==31733== by 0x5B6976: StreamTcpReassembleHandleSegment (stream-tcp-reassemble.c:3401)
==31733== by 0x5A5FA4: HandleEstablishedPacketToClient (stream-tcp.c:2090)
==31733== by 0x5A697B: StreamTcpPacketStateEstablished (stream-tcp.c:2336)

It does appear that the HTTP session is never completed, and that an
incomplete transaction is freed. However, in this case the put_file
storage is not freed.

This patch adds freeing of that storage to htp_tx_destroy_incomplete(),
which makes the valgrind leak report go away.