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

Pablo Neira Ayuso <[email protected]> Tue, 28 Jul 2026 12:45:59 +0200
Newsgroups gmane.comp.security.firewalls.netfilter.devel
Message-ID <amiIZyz2qIm2vkfX@chamomile>
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.