Impact
Suricata's SMB parser could retain force-completed transactions on flows where Suricata observed only one direction with payload. When the SMB transaction cap was reached, older transactions were marked parser-complete but not skipped for inspection in the missing direction, so cleanup would not reclaim them. A sustained one-directional SMB flow could therefore grow per-flow transaction state without bound and make cleanup re-scan an increasing transaction list, leading to CPU and memory exhaustion.
Patches
Upgrade to Suricata 8.0.6 or 7.0.17.
Workarounds
You can use a rule like alert smb any any -> any any (msg:"SURICATA SMB too many transactions"; app-layer-event:smb.too_many_transactions; bypass; classtype:protocol-command-decode; sid:1;)
References
https://redmine.openinfosecfoundation.org/issues/8629
Impact
Suricata's SMB parser could retain force-completed transactions on flows where Suricata observed only one direction with payload. When the SMB transaction cap was reached, older transactions were marked parser-complete but not skipped for inspection in the missing direction, so cleanup would not reclaim them. A sustained one-directional SMB flow could therefore grow per-flow transaction state without bound and make cleanup re-scan an increasing transaction list, leading to CPU and memory exhaustion.
Patches
Upgrade to Suricata 8.0.6 or 7.0.17.
Workarounds
You can use a rule like
alert smb any any -> any any (msg:"SURICATA SMB too many transactions"; app-layer-event:smb.too_many_transactions; bypass; classtype:protocol-command-decode; sid:1;)References
https://redmine.openinfosecfoundation.org/issues/8629