Re: [BUG?] success of adding interval elements to map/set depends on order

Hi Michal,

On Mon, 1 Jun 2026, at 1:19 PM, Michal Soltys wrote:
> Hi,
>
> Consider the following ruleset file:
>
> #!/usr/bin/nft -f
> flush ruleset
>
> table ip Main {
>    map snatmap {
>      typeof oifname . ip saddr : ip saddr
>      flags interval
>      elements = {
>        "egress0" . 10.192.0.88/29 comment "generic": 1.2.3.4,
>        "egress0" . 10.192.0.93 comment "sip": 5.6.7.8,
>      }
>      comment "SNAT map"
>    }
> }
>
> trying to load such ruleset fails with elements in this order will fail 
> with:
>
> /etc/nftables-test.conf:10:25-61: Error: Could not process rule: File exists
>                          "egress0" . 10.192.0.93 comment "sip": 5.6.7.8,
>                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> But if we swap the order of those two elements so the more narrow one is 
> present earlier, the rules will load successfully. Same applies for 
> manual adding via "nft add element". And same happens if it was a 
> regular set instead of a map.

Given the absence of the auto-merge flag, overlapping elements are supposed to be rejected. The consistent behaviour would be to reject both orderings. That these rules can ever be loaded successfully is an unequivocal bug.

Speaking of which, there have been various bugs concerning sets and maps over the years. If I may ask, which version of Linux and nftables are you using?

>
> This should probably either fail in both cases, or succeed in both cases ?
>
> Then there is also a question how that would/should behave in case of a 
> map, e.g. would
>
> snat ip to oifname . ip saddr map @snatmap comment "snat map"
>
> use 1.2.3.4 or 5.6.7.8 for 10.192.0.93 ?

Undefined behaviour. It would boil down to whichever is matched first. This sort of ambiguity demonstrates why overlapping elements must be rejected rather than be resolved by some notion of specificity.

--
Kerin Millar