From: Florian Westphal <fw@strlen.de>
To: Zhiling Zou <zhilinz@nebusec.ai>
Cc: netfilter-devel@vger.kernel.org, netdev@vger.kernel.org,
pablo@netfilter.org, phil@nwl.cc, kadlec@netfilter.org,
den@openvz.org, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, horms@kernel.org,
xmei5@asu.edu, kees@kernel.org, sbrivio@redhat.com,
vega@nebusec.ai
Subject: Re: [PATCH nf 1/1] netfilter: ipset: serialize kernel-side put-byindex with swap
Date: Sat, 1 Aug 2026 15:55:42 +0200 [thread overview]
Message-ID: <am363vHJsdnL3Ja-@strlen.de> (raw)
In-Reply-To: <df40376603e2a53a311d5ceea63240bedc11bdfc.1785583673.git.zhilinz@nebusec.ai>
Zhiling Zou <zhilinz@nebusec.ai> wrote:
> list:set garbage collection drops member set references through
> ip_set_put_byindex(), which resolves inst->ip_set_list[index] before
> __ip_set_put() takes ip_set_ref_lock. ip_set_swap() swaps both the set
> pointers and the corresponding refcounts while holding that same lock.
>
> If garbage collection looks up the old set pointer for an index and then
> loses the lock race to ip_set_swap(), it decrements the old object after
> its refcount has already been swapped away. This can trigger BUG_ON(ref
> == 0) when the other set had no references, or otherwise under-reference
> a set that is still reachable through the swapped index.
>
> Fix this by holding ip_set_ref_lock across the kernel-side lookup and
> refcount decrement. This keeps ip_set_put_byindex() paired with the same
> set/ref state that ip_set_swap() publishes, without changing normal
> list:set deletion or swap behaviour.
Looks like a duplicate of
https://patchwork.ozlabs.org/project/netfilter-devel/patch/20260722223832.3524006-1-xmei5@asu.edu/
prev parent reply other threads:[~2026-08-01 13:55 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-01 12:10 [PATCH nf 0/1] netfilter: ipset: serialize kernel-side put-byindex with swap Zhiling Zou
2026-08-01 12:10 ` [PATCH nf 1/1] " Zhiling Zou
2026-08-01 13:55 ` 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=am363vHJsdnL3Ja-@strlen.de \
--to=fw@strlen.de \
--cc=davem@davemloft.net \
--cc=den@openvz.org \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kadlec@netfilter.org \
--cc=kees@kernel.org \
--cc=kuba@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=sbrivio@redhat.com \
--cc=vega@nebusec.ai \
--cc=xmei5@asu.edu \
--cc=zhilinz@nebusec.ai \
/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.