Suricata

May be related to
https://redmine.openinfosecfoundation.org/issues/1399

Philippe Antoine wrote in #note-5:

Is this still an issue in Suricata 8 ? Would you have a pcap to test the supplied rules ?

I seem to have run into the same problem while working for fixes for another ticket ( #8459 ).

I'll share one or two SV tests.

1. Rule ordering: xbits setters sort after readers

Found while writing SV test for #8459. Present on `main` (checked
2026-10-21). Independent of firewall mode.

1. Symptom

Two TD rules matching the same packet, one with `xbits:set,X,track ip_src`
and one with `xbits:isset,X,track ip_src`: the `isset` rule does not alert.
Rule ordering is meant to put setters before readers, so this pattern should
work.

1. Cause

`SCSigGetXbitsType()` (`src/detect-engine-sigorder.c:406-460`) classifies a
rule for the hostbits / ippairbits ordering, but its two loops check different
keywords:

- MATCH list (readers: `isset` / `isnotset`): counts only `DETECT_XBITS` (`:415`).
- POSTMATCH list (writers: `set` / `unset` / `toggle`): counts only
`DETECT_HOSTBITS` (`:434`).

Result, with `NOT_USED=1 < READ=2 < SET_READ=3 < SET=4` and higher sorting
first (`SCSigLessThan`, `:539-540`):

hostbits ends up in the right order only because both sides are misclassified
in a way that still puts the setter first. xbits with `track ip_src|ip_dst`
maps to `VAR_TYPE_HOST_BIT` (`src/detect-xbits.c:309-314`), so it goes
through the same hostbits comparison and comes out reversed.

1. Possible fix

Have both loops count `DETECT_XBITS` and `DETECT_HOSTBITS`. This changes rule
ordering for any ruleset using xbits or hostbits, so it needs its own ticket
and tests (xbits and hostbits same-packet `set` -> `isset`, both `ip_src` and
`ip_pair`).

1. Not checked

- Whether `ip_pair` xbits (`SCSigOrderByIPPairbitsCompare`) hit the same
reversal; the code path suggests so.