Re: [PATCH nf-next] netfilter: nfnetlink_queue: hash queue instance by portid too

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Thu, Sep 17, 2026 at 06:36:34AM +0200, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > netlink_release() calls netlink_remove() before delivering the
> > NETLINK_URELEASE event. And a new queue instance can be created before
> > delivering such NETLINK_URELEASE event. This allows for two different
> > queue instances with the same portid to co-exist for a little while.
> > Since the instance that is going away is destroyed by portid via netlink
> > notifier, both the newly created instance and the one that is going away
> > with the same portid are destroyed.
> > 
> > Fixes: 7af4cc3fa158 ("[NETFILTER]: Add "nfnetlink_queue" netfilter queue handler over nfnetlink")
> > Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
> > ---
> > @Florian: this is the rare race that Clashiko uncover with your fix.
> >           This is a pre-existing issue. I have to check if nfnetlink_log
> > 	  is also affected.
> 
> AFAICS its complete bullshit report.

It's theoretical, yes.

> Needs threads that race to kill and resurrect the same queue all over
> again, constantly.

I think this can happen with different queue number and same netlink
portid.

> Don't do that, then?!
> What kind of userspace does this?!  I mean, what's the point?

The goal of my patch reject duplicates netlink portid.

> We could make nfqueue refcounted, like _log, but I see no reason
> whatsover.

I don't see how refcounting will fix this race.

The problem is that the netlink notifier path encounters two different
queue instances with the same portid, and it destroys both of them,
the new and the stale one.