Project

General

Profile

Actions

Bug #4200

open

Flows not deleted in bpf ipv4_maps

Added by Odin Jenseg over 3 years ago. Updated over 1 year ago.

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

Description

OS: CentOS 8
Suricata version: 6.0.0

It is observed that the ipv4_maps is growing until max limits, currently testing with map size of 627680, and the ipv4_fail counter is growing.

Observed that in line 429 in flow-manager.c (FlowManagerHashRowClearEvictedList), flows added to the evicted list does not run FlowBypassedTimeout, and these flows are not removed from the map. Changed this function to:

 420 static void FlowManagerHashRowClearEvictedList(FlowManagerTimeoutThread *td,
 421         Flow *f, struct timeval *ts, FlowTimeoutCounters *counters)
 422 {
 423     do {
 424         FLOWLOCK_WRLOCK(f);
 425         Flow *next_flow = f->next;
 426         f->next = NULL;
 427         f->fb = NULL;
 428
 429         //DEBUG_VALIDATE_BUG_ON(f->use_cnt > 0 || !FlowBypassedTimeout(f, ts, counters));
 430         if (f->use_cnt > 0 || !FlowBypassedTimeout(f, ts, counters)) {
 431             FLOWLOCK_UNLOCK(f);
 432             f = f->next;
 433             continue;
 434         }
 435
 436         FlowQueuePrivateAppendFlow(&td->aside_queue, f);
 437         /* flow is still locked in the queue */
 438
 439         f = next_flow;
 440     } while (f != NULL);
 441 }

and this seems to ensure that the map is not growing until the max. However, I am not that familiar with the code, so it might be reason not to it this way.

Another observation is that ipv4_maps_count does not reach zero when stopping the traffic towards Suricata, which I would expect and might in worst case bypass traffic that has never happened if it executed on the same IP/Ports.


Files

clipboard-202211270234-zpg5w.png (13 KB) clipboard-202211270234-zpg5w.png Odin Jenseg, 11/27/2022 01:34 AM
Actions

Also available in: Atom PDF