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.