Bug #9031
closed
Suricata fails to start with interface with /31 mask
Added by Aaron Morris over 5 years ago. Updated almost 5 years ago.
0%
Description
I have discovered that Suricata will not start in blocking mode when an interface has a /31 subnet mask when using an automatically generated pass list.
Suricata error:
[ERRCODE: SC_ERR_INVALID_ARGUMENTS(52)] - prefix or user NULL
Suricata: 4.0.13_8
Updated by Bill Meeks almost 5 years ago
Admittedly I'm very late responding to this bug report, but I just tested on Suricata 4.1.4_1 on pfSense-2.5-DEVEL. I can only reproduce this issue when I assign an invalid IP address to the interface for the given /31 netmask, so the code is working correctly although the error message could perhaps be a little more helpful. However, the error is being returned by the Suricata binary from code maintained by upstream. So nothing can be done on the pfSense side other than submitting a request upstream.
I believe this issue can be marked either RESOLVED or REJECTED at the descretion of the pfSense developer team.
Updated by Jim Pingle almost 5 years ago
Bill Meeks wrote:
I can only reproduce this issue when I assign an invalid IP address to the interface for the given /31 netmask
/31 is a valid mask, see RFC 3021 and FreeBSD supports it, so it's not exactly correct to say it's "invalid". Any address could be masked /31 since there is no null route or broadcast in a /31. Unless I'm misunderstanding what you're saying you tested there.
If Suricata rejects a /31 address, that should be considered a bug in Suricata and raised upstream.
Updated by Bill Meeks almost 5 years ago
I don't mean to say the /31 netmask is invalid. I was multitasking at the time and now I'm not sure now what I saw with my testing. I agree with you that a /31 should work on anything. I believe the problem might really be in the Suricata binary's functions for adding IP addresses to a Radix tree. They do that for easy searching, and the custom blocking plugin uses that Radix tree tool to store Pass List IP addresses. It might be that certain ranges of IPs and /31 netmasks are confusing something in the Radix tree code, particularly when a passed range has a netmask that overlaps a previously stored range. Hard to explain in a single paragraph ... :).
Anyway, scratch closing this issue and I will look further into the Suricata binary code. It may also have something to do with the particular way I am calling the Radix tree function in the custom blocking plugin.
Updated by Bill Meeks almost 5 years ago
Okay. Found the source of this bug and it is fixed in this pull request: https://github.com/pfsense/FreeBSD-ports/pull/648.
The root cause was within the custom blocking plugin. Suricata uses a Radix Tree to store IP addresses for rapid searching. When inserting an entry into the tree you can pass an optional "user data" pointer to be associated with that IP entry. Turns out that parameter is not always optional. The /31 subnet situation was an edge case where that parameter was not optional. It does not really matter what it is, but it can't be NULL. So the fix was to just always pass in a "user data" pointer when adding an entry to the Radix Tree. The pointer is otherwise never used, but it makes the Suricata Radix Tree code happy ... :).
The new Suricata packge version will 4.1.4_2. This issue can be marked as RESOLVED.
Updated by e 1/1 almost 5 years ago
Bill Meeks wrote:
Okay. Found the source of this bug and it is fixed in this pull request: https://github.com/pfsense/FreeBSD-ports/pull/648.
The root cause was within the custom blocking plugin. Suricata uses a Radix Tree to store IP addresses for rapid searching. When inserting an entry into the tree you can pass an optional "user data" pointer to be associated with that IP entry. Turns out that parameter is not always optional. The /31 subnet situation was an edge case where that parameter was not optional. It does not really matter what it is, but it can't be NULL. So the fix was to just always pass in a "user data" pointer when adding an entry to the Radix Tree. The pointer is otherwise never used, but it makes the Suricata Radix Tree code happy ... :).
The new Suricata packge version will 4.1.4_2. This issue can be marked as RESOLVED.
Sir, thank you very much for this fix!
One pfSense instance I manage had Suricata crashing at start since a couple of months ago on all interfaces, with the same message:
[ERRCODE: SC_ERR_INVALID_ARGUMENTS(52)] - prefix or user NULL
Pass lists were all on auto.
What's curious is that none of the interfaces had a /31 mask. It was either /32 (PPPOE WAN) or /24 (internal VLAN'ed segments).
Updated by Bill Meeks almost 5 years ago
I did not do a lot of research trying to figure out the logic of the Suricata Radix Tree code, but only certain combinations of IP netblocks would trigger it. What I did was just alter the custom blocking plugin code so that it always passes in a value instead of NULL. Hopefully this change takes of that problem forever.