Project

General

Profile

Actions
Copy link

Bug #16771

open

Suricata Blocks page triggers PHP error

Added by Nathan S 6 days ago. Updated 3 days ago.

Status:
Feedback
Priority:
Normal
Assignee:
Marcos M
Category:
Suricata
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Affected Version:
Affected Plus Version:
26.03
Affected Architecture:
amd64

Description

I realize this doesn't make any sense looking at the last 60 days commits. I only experienced this bug after loading up the 26-03RC and after. Prior stable version did not demonstrate behavior (at least that I witnessed).

Previous forums convo:
https://forum.netgate.com/topic/200348/suricata-blocks-page?_=1775096443293

This seems to be very repeatable.
The files behind this do not appear to contain borked ipv6 or ipv4 addresses.
Everything is parsed correctly on the individual interface alert pages.

The production 26-03 seems to give slightly less feedback on the crash report. Instead of "ip2long('\x08\xD8\x00d') or other random string the production system only reports that the files and strings had issues: "ip2long()" as newest:

=================
"Crash report begins. Anonymous machine information:

amd64
16.0-CURRENT
FreeBSD 16.0-CURRENT #36 plus-RELENG_26_03-n256531-4923e82e59d1: Fri Mar 20 18:22:49 UTC 2026 :/var/jenkins/workspace/pfSense-Plus-snapshots-26_03-main/obj/amd64/TVcqnR7U/var/jenkins/workspace/pfSe

Crash report details:

PHP Errors:
[01-Apr-2026 20:20:25 America/Denver] PHP Fatal error: Uncaught ValueError: ip2long(): Argument #1 ($ip) must not contain any null bytes in /etc/inc/util.inc:1443
Stack trace:
#0 /etc/inc/util.inc(1443): ip2long()
#1 /etc/inc/util.inc(1386): is_ipaddrv4()
#2 /usr/local/www/suricata/suricata_blocked.php(399): is_ipaddr()
#3 {main}
thrown in /etc/inc/util.inc on line 1443

No FreeBSD crash data found.
"

Actions
Copy link
 #1

Updated by Nathan S 6 days ago

confirm diag>tables>snort2c at this last error have zero ipv6 listed and no otherwise notable IP errors and renders fine. 229 records on the block list.

Actions
Copy link
 #2

Updated by Nathan S 5 days ago

I found an extremely old posting from 2015 discussing that ip2long might fail with a leading zero in a dotted quad.

Reviewing my actual block.log file, there are indeed the occasional 'leading' zero .... like a 13.222.210.0:12345

Any place larger than a /24 would have a legit .0 addressable that could test this. I've been scratching my head with this off and on for a while now and so far this is the only idea that has any merit.

Just a few weeks ago this was in the php github:
https://github.com/php/php-src/issues/21295

Actions
Copy link
 #3

Updated by Marcos M 5 days ago

  • Subject changed from Suricata Blocks page error to Suricata Blocks page triggers PHP error
  • Status changed from New to Feedback
  • Assignee set to Marcos M

I've added null byte checks to is_ipaddrv4() with dda07c0a46c83cd79fbd3e07f86be2120b73eeac. You can add the following patch for now: Show

Actions
Copy link
 #4

Updated by Nathan S 4 days ago

Seems promising.

Actions
Copy link
 #5

Updated by Nathan S 3 days ago

Day later and no problems so far.

I never actually got around to performing the same test code from the AIX ip2long ticket as you provided a tweak before I spun up a machine to test it. Did you confirm it was the same behavior between AIX/FreeBSD/pfSense?

Actions
Copy link

Also available in: Atom PDF