Project

General

Profile

Actions

Bug #4078

closed

smb: post-GAP file handling

Added by Victor Julien about 4 years ago. Updated about 4 years ago.

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

Description

The issue addressed in #3400 is not completely fixed. The transactions are cleaned up properly, however the files are not.

As the files list and the transactions are only loosely connected, the files need to be explicitly handled. Transactions are freed based on their "progress", files based on their "state". If the "state" stays "FILE_STATE_OPEN", the file won't be freed until the end of the flow. The post-GAP handling doesn't explicitly change the file state and therefore the file is not freed. This can lead to a situation where the file list contains an ever increasing amount of "open" files that are never freed or otherwise used, but do consume memory and slow down various operations that walk the file list.

Making things worse is the feedback loop of these smb sessions becoming ever more expensive, leading the pkt loss, contributing to more of these "dangling" files, leading to more loss, etc.


Related issues 1 (0 open1 closed)

Copied from Suricata - Bug #3699: smb: post-GAP file handlingClosedVictor JulienActions
Actions

Also available in: Atom PDF