All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.