Project

General

Profile

Actions

Bug #1928

closed

flow bypass leads to memory errors

Added by Victor Julien over 7 years ago. Updated over 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

Description

=================================================================
==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)

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:

      if ((state == FLOW_STATE_LOCAL_BYPASSED) ||
              (state == FLOW_STATE_CAPTURE_BYPASSED)) {
          if (FlowForceReassemblyNeedReassembly(f, &server, &client) == 1) {
              FlowForceReassemblyForFlow(f, server, client);
          }
          return 1;
      }

This leads to packets going through the engine with a pointer to a now freed/recycled flow.

Actions #1

Updated by Victor Julien over 7 years ago

  • Description updated (diff)
Actions #2

Updated by Victor Julien over 7 years ago

  • Status changed from Assigned to Closed
Actions

Also available in: Atom PDF