Bug #6735
opensetting variables with --set leads to segfault
Description
Trying to incorrectly set threading 'threads' count leads to a segfault before suricata starts. This was done in 8 but likely affects previous version.
suricata -c suricata.yaml -i xxx -S suricata.rules --set threading.cpu-affinity.worker-cpu-set.threads=28
Notice: suricata: This is Suricata version 8.0.0-dev (244a35d53 2024-01-30) running in SYSTEM mode [LogVersion:suricata.c:1147]
Segmentation fault
For reference, the correct way to set this is through a 'array'.
--set threading.cpu-affinity.2.worker-cpu-set.threads=28
Updated by Philippe Antoine 28 days ago
- Status changed from New to Feedback
- Affected Versions deleted (
8.0.0)
I do not reproduce on 8.0.0 final, do you ?
Updated by Corey Thomas 28 days ago · Edited
I am still seeing it on master 8.
Maybe it's triggered by the config we have in QA ?
That may be a bit out of date, but I'm not sure that matters since you are setting a var?
(edit: this is actually from your PR about TLPW2 using files and having more uptime, so this is 7 as the version says)
suricata -c suricata.yaml -S suricata.rules --af-packet --no-random -k none --set 'vars.address-groups.EXTERNAL_NET=any' --set threading.cpu-affinity.worker-cpu-set.threads=28
Warning: debug: error opening file suricata.json: No such file or directory [SCLogInitFileOPIface:util-debug.c:854]
Notice: suricata: This is Suricata version 7.0.12-dev (8023d468a 2025-07-11) running in SYSTEM mode [LogVersion:suricata.c:1159]
Segmentation fault
Updated by Corey Thomas 28 days ago · Edited
still see it in 8 too
Notice: suricata: This is Suricata version 8.0.1-dev (07b7f3674 2025-07-10) running in SYSTEM mode [LogVersion:suricata.c:1208]
Segmentation fault
Updated by Corey Thomas 28 days ago
Doing a
`--set 'threading.["cpu-affinity"].["worker-cpu-set"].threads=28`does not segfault and errors out on my var log dir not existing.
Yes, I think the fix is to not allow setting a mismatching type. It's pretty benign overall.
Updated by Philippe Antoine 24 days ago
- Status changed from Feedback to New
- Affected Versions 8.0.0 added
Updated by Corey Thomas 21 days ago
No, but tracing getopt() from suricata.c looks like conf.c SCConfNodeGetNodeOrCreate() is where things get created. I would guess that's where a check should be but not sure if it's omniscient enough to know what should and shouldn't be strings/numbers/arrays.