Suricata

Affected version: 8.0.7 (built from source, Linux). Current main (4badfd1) has the same dependency (sawp-modbus = "~0.13.1") and calls matches() in the same way, so I expect it to be affected too; I have not run main.

Summary¶

With rules/modbus-events.rules loaded, every well-formed FC 3 / FC 4 transaction raises SURICATA Modbus Data mismatch (sid 2250008). In the eve record the response carries "error_flags": "DATA_VALUE".

Root cause¶

sawp-modbus 0.13.1 (latest on crates.io) Message::matches() checks a read response against its request with ceil(quantity/8), the bit-read formula, in the (Read::Response, Read::Request) arm and in the symmetric arm. That arm also handles register reads (FC 3/4), where the expected byte count is 2*quantity. So every correct register-read response with quantity >= 1 gets DATA_VALUE, and rust/src/modbus/modbus.rs turns that into ModbusEvent::ValueMismatch.

Upstream report: https://github.com/CybercentreCanada/sawp/issues/13

Steps to reproduce¶

1. Load modbus-events.rules with Modbus enabled on port 502.
2. suricata -r mbtcp-read-holding-registers-ok.pcap (attached; synthetic, one FC 3 request for 11 registers, 00 01 00 00 00 06 01 03 00 00 00 0b, plus its correct 22-octet response).
3. eve.json contains one alert, SURICATA Modbus Data mismatch.

Sweeping the quantity (1, 2, 10, 11, 12, 125) gives one alert per transaction every time.

Expected¶

No alert when the response byte count equals 2 * quantity.

Impact¶

On networks that poll registers, which is the usual Modbus workload, the rule fires on essentially every transaction. That makes it useless and buries real data-length mismatches.