nftables: regression/bug in interval set lookup in 6.18.14, still present in 7.1.5

nftables: regression/bug in interval set lookup in 6.18.14, still present in 7.1.5

[Adam Tulinius]

Hi there

Sorry to post here, I tried creating this bug report on bugzilla, but it seems down :(

I believe I have found a regression in kernel 6.18.14/6.18.15 w.r.t. interval set lookups, that still affects kernel 7.1.5. Sometimes the lookup will fail during table re-creation, and nftables will behave as if the element was missing, even if it isn't.

We found this while deploying kernel 6.18.35 to our kubernetes environment, where we started noticing connection refused rates of about 0.05%. Further testing revealed that this happens when we reload our nftables rules (every 20s), and bisecting through kernel versions tells me that 6.18.13 is the last good kernel. I haven't been able to test on 6.18.14, but as far as I understand 6.18.15 was released shortly after, and I know 6.18.15 is affected.

To reproduce I did this:

Ran a fast responding web server on port 127.0.0.1:3000 .

Loaded these rules in a loop (e.g. `while $(sleep 0.1); do sudo nft -f bar.nft ; done`):

delete table nft_rbtree_repro
create table nft_rbtree_repro

table nft_rbtree_repro {
        set local_ips {
                type ipv4_addr
                flags interval
                elements = {
                        127.0.0.1,
                }
        }

        chain egress-fw {
                ip daddr @local_ips accept
                meta nftrace set 1 mark set 0x00007ff8
        }

        chain output {
                type filter hook output priority filter; policy accept;

                tcp dport 3000 jump egress-fw
                tcp dport 3000 meta mark 0x00007ff8 meta nftrace set 1 reject
        }
}

Ran some requests: `echo "GET http://127.0.0.1:3000" | vegeta attack -rate=1000/s -duration=20s -insecure -keepalive=false | vegeta report`.

On kernel 6.18.13 no connections will fail, on 6.18.15 about 3-10 will fail during the 20 seconds, and kernel 7.1.5 shows the same affected behaviour.

Please let me know if I can provide more information or testing.

Thanks in advance.

Best regards
Adam Tulinius

Re: nftables: regression/bug in interval set lookup in 6.18.14, still present in 7.1.5

[Pablo Neira Ayuso]

Hi,

On Tue, Jul 28, 2026 at 11:16:40AM +0200, Adam Tulinius wrote:
> Hi there
> 
> Sorry to post here, I tried creating this bug report on bugzilla, but it seems down :(
> 
> I believe I have found a regression in kernel 6.18.14/6.18.15 w.r.t. interval set lookups, that still affects kernel 7.1.5. Sometimes the lookup will fail during table re-creation, and nftables will behave as if the element was missing, even if it isn't.
> 
> We found this while deploying kernel 6.18.35 to our kubernetes environment, where we started noticing connection refused rates of about 0.05%. Further testing revealed that this happens when we reload our nftables rules (every 20s), and bisecting through kernel versions tells me that 6.18.13 is the last good kernel. I haven't been able to test on 6.18.14, but as far as I understand 6.18.15 was released shortly after, and I know 6.18.15 is affected.
> 
> To reproduce I did this:
> 
> Ran a fast responding web server on port 127.0.0.1:3000 .
> 
> Loaded these rules in a loop (e.g. `while $(sleep 0.1); do sudo nft -f bar.nft ; done`):
> 
> delete table nft_rbtree_repro
> create table nft_rbtree_repro
> 
> table nft_rbtree_repro {
>         set local_ips {
>                 type ipv4_addr
>                 flags interval
>                 elements = {
>                         127.0.0.1,
>                 }
>         }
> 
>         chain egress-fw {
>                 ip daddr @local_ips accept
>                 meta nftrace set 1 mark set 0x00007ff8
>         }
> 
>         chain output {
>                 type filter hook output priority filter; policy accept;
> 
>                 tcp dport 3000 jump egress-fw
>                 tcp dport 3000 meta mark 0x00007ff8 meta nftrace set 1 reject
>         }
> }
> 
> Ran some requests: `echo "GET http://127.0.0.1:3000" | vegeta attack -rate=1000/s -duration=20s -insecure -keepalive=false | vegeta report`.
> 
> On kernel 6.18.13 no connections will fail, on 6.18.15 about 3-10 will fail during the 20 seconds, and kernel 7.1.5 shows the same affected behaviour.
> 
> Please let me know if I can provide more information or testing.

This is sufficient, thanks, I will be preparing a patch asap.