Bug #1928
Updated by Victor Julien about 8 years ago
<pre>
=================================================================
==30105==ERROR: AddressSanitizer: heap-use-after-free on address 0x61200007ac5c at pc 0x0000007b7b99 bp 0x7fb64b8e9760 sp 0x7fb64b8e9750
READ of size 2 at 0x61200007ac5c thread T3 (W#03-eth3)
#0 0x7b7b98 in StreamTcpPacket /home/victor/dev/suricata/src/stream-tcp.c:4448
#1 0x7ba54d in StreamTcp /home/victor/dev/suricata/src/stream-tcp.c:4918
#2 0x69003c in FlowWorker /home/victor/dev/suricata/src/flow-worker.c:194
#3 0x7f127b in TmThreadsSlotVarRun /home/victor/dev/suricata/src/tm-threads.c:130
#4 0x756543 in TmThreadsSlotProcessPkt /home/victor/dev/suricata/src/tm-threads.h:178
#5 0x75b6e7 in AFPReadFromRing /home/victor/dev/suricata/src/source-af-packet.c:894
#6 0x75fa40 in ReceiveAFPLoop /home/victor/dev/suricata/src/source-af-packet.c:1421
#7 0x7f2357 in TmThreadsSlotPktAcqLoop /home/victor/dev/suricata/src/tm-threads.c:334
#8 0x7fb651d1e6f9 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x76f9)
#9 0x7fb650e92b5c in clone (/lib/x86_64-linux-gnu/libc.so.6+0x106b5c)
0x61200007ac5c is located 156 bytes inside of 296-byte region [0x61200007abc0,0x61200007ace8)
freed by thread T10 (FM#01) here:
#0 0x7fb6536e42ca in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x982ca)
#1 0x68c924 in FlowFree /home/victor/dev/suricata/src/flow-util.c:80
#2 0x671d42 in FlowUpdateSpareFlows /home/victor/dev/suricata/src/flow.c:141
#3 0x67f9e1 in FlowManager /home/victor/dev/suricata/src/flow-manager.c:708
#4 0x7f3cc6 in TmThreadsManagement /home/victor/dev/suricata/src/tm-threads.c:709
#5 0x7fb651d1e6f9 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x76f9)
previously allocated by thread T0 (Suricata-Main) here:
#0 0x7fb6536e4602 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602)
#1 0x68ba39 in FlowAlloc /home/victor/dev/suricata/src/flow-util.c:60
#2 0x673f90 in FlowInitConfig /home/victor/dev/suricata/src/flow.c:416
#3 0x7e5dfd in main /home/victor/dev/suricata/src/suricata.c:2480
#4 0x7fb650dac82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
</pre>
The reason is that on flow bypass, the flow timeout handling is triggered which may create up to 3 pseudo packets that hold a reference to the flow. However, in the bypass case the code signals to the timeout logic that the flow can be freed unconditionally by returning 1 here:
<pre>
if ((state == FLOW_STATE_LOCAL_BYPASSED) ||
(state == FLOW_STATE_CAPTURE_BYPASSED)) {
if (FlowForceReassemblyNeedReassembly(f, &server, &client) == 1) {
FlowForceReassemblyForFlow(f, server, client);
}
return 1;
}
</pre>
This leads to packets going through the engine with a pointer to a now freed/recycled flow.