Bug 13926

Summary: Suricata Hyperscan cache grows indefinitely with no automatic pruning
Product: IPFire Reporter: Adam G <ag>
Component: ---Assignee: Stefan Schantl <stefan.schantl>
Status: ON_QA --- QA Contact:
Severity: Minor Usability    
Priority: - Unknown - CC: adolf.belka, michael.tremer, stefan.schantl
Version: 2   
Hardware: all   
OS: Unspecified   

Description Adam G 2026-01-14 13:30:50 UTC 
Description
===========

Suricata's Hyperscan (HS) MPM cache feature stores compiled pattern contexts in /var/cache/suricata/sgh/ to improve performance. These cache files accumulate over time as rules change or new signatures are processed. There is currently no mechanism in Suricata 8.0.2 to prune stale or unused files, leading to unbounded growth of the directory. This can eventually fill up the filesystem on installations with limited storage. One case reached 1.4 GiB.

A related symptom (inflated backup sizes) was fixed in December 2025 by excluding /var/cache/suricata/sgh/ from backups by Adolf. The underlying cache growth remains unresolved.

Steps to Reproduce
==================

Install current IPFire (2.29 Core Update 199 or later) with Suricata IPS enabled.
Run the system normally with network traffic passing through for several weeks or months.
Periodically check the cache directory size:
du -sh /var/cache/suricata/sgh/
or count files:
find /var/cache/suricata/sgh/ -type f | wc -l
Observe steady growth in size and file count.

Expected Behaviour
==================

The cache directory should remain bounded in size. Stale or unused cache files should be automatically pruned (e.g., based on age or when rules change), or the feature should include built-in limits to prevent disk exhaustion.

Actual Behaviour
================

The directory grows without limit. No pruning occurs. Files are created but never deleted automatically.

Additional Information
======================

Original discussion (December 2025): https://lists.ipfire.org/development/F3960F97-D2F0-4076-B51F-EF3D60908EFF@ipfire.org/T/#t
Backup exclusion patch already applied (prevents backup bloat but not the growth itself).
Upstream Suricata is aware and working on a fix:
Open PR implementing pruning based on file mtime and configurable max age: https://github.com/OISF/suricata/pull/14590 (created 11 Jan 2026, still open with requested changes).
Related OISF ticket: https://redmine.openinfosecfoundation.org/issues/7830
Current Suricata stable release (13 Jan 2026) is 8.0.3, but the PR is not merged yet, so pruning is not available.
Comment 1 grisu127 2026-01-15 14:00:04 UTC 
checked on my device (PC Engines - apu4):

The directory contained 6786 files - 6,14 GB. Deleting the files reduced disk usage from 75% to 25%.
Comment 2 Adolf Belka 2026-01-16 20:50:20 UTC 
(In reply to Adam G from comment #0)
> Upstream Suricata is aware and working on a fix:
> Open PR implementing pruning based on file mtime and configurable max age:
> https://github.com/OISF/suricata/pull/14590 (created 11 Jan 2026, still open
> with requested changes).

PR #14590 was closed on Jan 14th and PR #14617 opened
PR #14617 was closed on Jan 16th and PR #14630 opened
PR #14630 was merged on Jan 16th.

So a final version of the pruni9ng process was reviewed and agreed by the suricata devs and has been merged into their main branch.

Not sure when this will now get into a release, but it has been merged into their main branch so the next release should make it available.
Comment 3 Stefan Schantl 2026-01-21 12:30:07 UTC 
Finally a fix has been landed and merged in the suricata git.

https://github.com/OISF/suricata/pull/14630

I've grabbed those patches, merged them to a single patchfile and applied them to the suricata 8.0.3 source code.

https://git.ipfire.org/?p=people/stevee/ipfire-2.x.git;a=commit;h=a11efb0cc3c4e873be47f2b364ff9ab417ae2b93
Comment 4 Michael Tremer 2026-01-21 13:32:09 UTC 
(In reply to Stefan Schantl from comment #3)
> Finally a fix has been landed and merged in the suricata git.
> 
> https://github.com/OISF/suricata/pull/14630
> 
> I've grabbed those patches, merged them to a single patchfile and applied
> them to the suricata 8.0.3 source code.
> 
> https://git.ipfire.org/?p=people/stevee/ipfire-2.x.git;a=commit;
> h=a11efb0cc3c4e873be47f2b364ff9ab417ae2b93

Could you please post this to the list?
Comment 5 Stefan Schantl 2026-01-23 07:09:31 UTC 
I've sent the patchset to the development
mailing list.

https://lists.ipfire.org/development/20260123053102.389490-1-stefan.schantl@ipfire.org/T/#u

The patched binary seems to work well. All old cache
files have been deleted during first startup.
Comment 6 Michael Tremer 2026-01-23 10:35:15 UTC 
Thank you. Merged.
Comment 7 Adam G 2026-01-24 19:03:25 UTC 
I've tested this patchset on the latest x86_64 nightly (139af25a) and I can confirm the SGH directory has reduced in size:

Before update:

# du -sh /var/cache/suricata/sgh/
3.6G	/var/cache/suricata/sgh/

After update and reboot:

# du -sh /var/cache/suricata/sgh/
55M	/var/cache/suricata/sgh/
Comment 8 Adam G 2026-01-27 23:11:37 UTC 
After a few more days the cache has increased further:

# du -sh /var/cache/suricata/sgh/
546M	/var/cache/suricata/sgh/

The default cache retention is set to 7 days in `/etc/suricata/suricata.yaml`:

```
sgh-mpm-caching: yes
  sgh-mpm-caching-max-age: 7d
  sgh-mpm-caching-path: /var/cache/suricata/sgh
```

Suricata logs this correctly as nothing cached is older than 7 days yet:

```
22:30:57	suricata:	[8258] <Info> -- Rule group caching - loaded: 66 newly cached: 0 total cacheable: 66
22:30:57	suricata:	[8258] <Info> -- Rule group cache pruning removed 0/555 of HS caches due to version-incompatibility (not v2) or age (older than 2026-01-20 22:30:57)
```
Comment 10 Adolf Belka 2026-01-30 21:20:25 UTC 
I just tested my vm with update from CU199 to CU200 Testing.  sgh was 59M with CU199 and after updating to CU200 sgh was 16M

So the pruning is confirmed for me on my vm system.