Linux Netfilter development
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Adam Tulinius <mail@adamtulinius.dk>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: nftables: regression/bug in interval set lookup in 6.18.14, still present in 7.1.5
Date: Tue, 28 Jul 2026 12:45:59 +0200	[thread overview]
Message-ID: <amiIZyz2qIm2vkfX@chamomile> (raw)
In-Reply-To: <589d243b-3d88-4138-9786-1bbb4347e79d@app.fastmail.com>

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.

      reply	other threads:[~2026-07-28 10:46 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-28  9:16 nftables: regression/bug in interval set lookup in 6.18.14, still present in 7.1.5 Adam Tulinius
2026-07-28 10:45 ` Pablo Neira Ayuso [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=amiIZyz2qIm2vkfX@chamomile \
    --to=pablo@netfilter.org \
    --cc=mail@adamtulinius.dk \
    --cc=netfilter-devel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox