From: Florian Westphal <fw@strlen.de>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: syzbot <syzbot+4924a0edc148e8b4b342@syzkaller.appspotmail.com>,
coreteam@netfilter.org, davem@davemloft.net, edumazet@google.com,
horms@kernel.org, kuba@kernel.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, netfilter-devel@vger.kernel.org,
pabeni@redhat.com, phil@nwl.cc, syzkaller-bugs@googlegroups.com
Subject: Re: [syzbot] [netfilter?] WARNING in nft_map_deactivate
Date: Thu, 19 Feb 2026 16:17:19 +0100 [thread overview]
Message-ID: <aZcpf7Bek9mokzU0@strlen.de> (raw)
In-Reply-To: <aZcBeD8NCE5k7zeC@chamomile>
Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> This is an interval set allocating a new array that is allocated with
> GFP_KERNEL (rbtree/pipapo follow a similar approach), I suspect fault
> injection is making this memory allocation fail.
>
> Then, this WARN_ON_ONCE below triggers:
>
> static void nft_map_deactivate(const struct nft_ctx *ctx, struct nft_set *set)
> {
> struct nft_set_iter iter = {
> .genmask = nft_genmask_next(ctx->net),
> .type = NFT_ITER_UPDATE,
> .fn = nft_mapelem_deactivate,
> };
>
> set->ops->walk(ctx, set, &iter);
> WARN_ON_ONCE(iter.err);
>
> For the traceback below, it should be possible to add NFT_ITER_RELEASE
> to skip the allocation.
Agreed.
> But there are other paths where this can happen too, I am looking into
> making these nft_map_activate/nft_map_deactivate function never fail
> in the second stage, this is the idea:
>
> - For anonymous sets, the allocation (clone) can be skipped since they
> are immutable.
Right, there is no need to clone anon sets.
> - For non-anonymous sets, add a .clone interface to nft_set_ops so
> the clone is not done from the
Yes, that would help. However, I'm not sure its needed.
For 2nd stage that cannot fail, all inserts/deletes already completed,
i.e. there is already a clone present that is re-used, no new clone
happens.
The only exception that I can see is the "release" case you mention.
In that case, we had no delete or add, so the clone pointer is NULL.
With a new iter type we could detect this and just re-use the live
copy instead of making an unnecessary copy.
Or did I miss something?
prev parent reply other threads:[~2026-02-19 15:17 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-19 9:53 [syzbot] [netfilter?] WARNING in nft_map_deactivate syzbot
2026-02-19 12:26 ` Pablo Neira Ayuso
2026-02-19 15:17 ` Florian Westphal [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=aZcpf7Bek9mokzU0@strlen.de \
--to=fw@strlen.de \
--cc=coreteam@netfilter.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pablo@netfilter.org \
--cc=phil@nwl.cc \
--cc=syzbot+4924a0edc148e8b4b342@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
/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.