[PATCH net v3] netfilter: conntrack: avoid recursive master destruction

[PATCH net v3] netfilter: conntrack: avoid recursive master destruction

[Daehyeon Ko]

A conntrack holds a reference to its master. Userspace can build an
unbounded acyclic chain through ctnetlink. Expectation producers can do the
same: an nft ct expectation can attach its helper to an unconfirmed
expected child and arm the next expectation with that child as master. The
H.323 Q.931 helper can also propagate itself through call-forwarding
expectations.

When only child-held references remain, destroying the leaf calls
nf_ct_put() on its master. If that was the final reference, nf_ct_put()
recurses into nf_ct_destroy(). Repeating this at each level exhausts the
task stack and panics.

Nested expectations are existing helper semantics, and CTA_TUPLE_MASTER
was introduced for conntrackd state replication. Avoid per-producer
restrictions. Decrement the master's refcount directly, then free the
current conntrack. If the refcount reached zero, continue destroying the
master in the same invocation. This preserves existing constructors while
bounding stack use.

Fixes: 5faa1f4cb5a1 ("[NETFILTER]: nf_conntrack_netlink: add support to related connections")
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/179127347858.434549.11821822167265441355@kernel.org
Assisted-by: LLM
Signed-off-by: Daehyeon Ko <4ncienth@gmail.com>
---
v3:
- restore iterative destruction after Sashiko identified nft expectation
  paths that bypass v2
- document conntrackd compatibility and expectation producers
- do not carry Florian's v2 Reviewed-by to the changed patch
v2: https://patch.msgid.link/20261002165601.1754467-1-4ncienth@gmail.com
- replace v1 with ctnetlink entry-point restrictions
v1: https://patch.msgid.link/20261001180224.1018290-1-4ncienth@gmail.com

The source reproducer remains available privately on request. V3 has the same
code and stable patch-id 033ffbf1094d as v1. Code-identical earlier net and
exact v6.12.105 6,000-entry userns runs reclaimed every conntrack without a
crash marker. On fresh net 0984ebc63179, nf_conntrack_core.o builds W=1 clean.
The patch applies to current net, Torvalds, net-next, linux-next, v7.3-rc5 and
v6.12.105. Strict checkpatch is clean. allyesconfig and allmodconfig W=1 were
not run.

 net/netfilter/nf_conntrack_core.c | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
index d0d9e5ea84a095..0ce6141b3dfd70 100644
--- a/net/netfilter/nf_conntrack_core.c
+++ b/net/netfilter/nf_conntrack_core.c
@@ -592,6 +592,10 @@ static void warn_on_keymap_list_leak(const struct net *net)
 void nf_ct_destroy(struct nf_conntrack *nfct)
 {
 	struct nf_conn *ct = (struct nf_conn *)nfct;
+	struct nf_conn *master;
+	bool destroy_master;
+
+again:
 
 	WARN_ON(refcount_read(&nfct->use) != 0);
 
@@ -610,10 +614,17 @@ void nf_ct_destroy(struct nf_conntrack *nfct)
 	 */
 	nf_ct_remove_expectations(ct);
 
-	if (ct->master)
-		nf_ct_put(ct->master);
+	master = ct->master;
+	destroy_master = master &&
+		refcount_dec_and_test(&master->ct_general.use);
 
 	nf_conntrack_free(ct);
+
+	if (destroy_master) {
+		ct = master;
+		nfct = &ct->ct_general;
+		goto again;
+	}
 }
 EXPORT_SYMBOL(nf_ct_destroy);
 
-- 
2.55.0

Re: [PATCH net v3] netfilter: conntrack: avoid recursive master destruction

[netdev-bot+sinfo]

Hi!

This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:

 - How the issue was discovered, e.g. hit in production, hit during
   development, syzbot report, manual code inspection, LLM or static
   analysis tool scan.

Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account. If the series needs another revision for
other reasons, please include the information in the commit messages
then.

The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.

Re: [PATCH net v3] netfilter: conntrack: avoid recursive master destruction

[Florian Westphal]

Daehyeon Ko <4ncienth@gmail.com> wrote:
> A conntrack holds a reference to its master. Userspace can build an
> unbounded acyclic chain through ctnetlink. Expectation producers can do the
> same: an nft ct expectation can attach its helper to an unconfirmed
> expected child and arm the next expectation with that child as master. The
> H.323 Q.931 helper can also propagate itself through call-forwarding
> expectations.
> 
> When only child-held references remain, destroying the leaf calls
> nf_ct_put() on its master. If that was the final reference, nf_ct_put()
> recurses into nf_ct_destroy(). Repeating this at each level exhausts the
> task stack and panics.
> 
> Nested expectations are existing helper semantics, and CTA_TUPLE_MASTER
> was introduced for conntrackd state replication. Avoid per-producer
> restrictions. Decrement the master's refcount directly, then free the
> current conntrack. If the refcount reached zero, continue destroying the
> master in the same invocation. This preserves existing constructors while
> bounding stack use.
> 
> Fixes: 5faa1f4cb5a1 ("[NETFILTER]: nf_conntrack_netlink: add support to related connections")
> Cc: stable@vger.kernel.org
> Link: https://patch.msgid.link/179127347858.434549.11821822167265441355@kernel.org
> Assisted-by: LLM
> Signed-off-by: Daehyeon Ko <4ncienth@gmail.com>

Acked-by: Florian Westphal <fw@strlen.de>

That said, ignoring the source of the problem is not good.

I see no point whatsoever for a expected connection to have a
non-control connection as its master.

Re: [PATCH net v3] netfilter: conntrack: avoid recursive master destruction

[Pablo Neira Ayuso]

On Wed, Oct 07, 2026 at 10:48:48AM +0200, Florian Westphal wrote:
> Daehyeon Ko <4ncienth@gmail.com> wrote:
> > A conntrack holds a reference to its master. Userspace can build an
> > unbounded acyclic chain through ctnetlink. Expectation producers can do the
> > same: an nft ct expectation can attach its helper to an unconfirmed
> > expected child and arm the next expectation with that child as master. The
> > H.323 Q.931 helper can also propagate itself through call-forwarding
> > expectations.
> > 
> > When only child-held references remain, destroying the leaf calls
> > nf_ct_put() on its master. If that was the final reference, nf_ct_put()
> > recurses into nf_ct_destroy(). Repeating this at each level exhausts the
> > task stack and panics.
> > 
> > Nested expectations are existing helper semantics, and CTA_TUPLE_MASTER
> > was introduced for conntrackd state replication. Avoid per-producer
> > restrictions. Decrement the master's refcount directly, then free the
> > current conntrack. If the refcount reached zero, continue destroying the
> > master in the same invocation. This preserves existing constructors while
> > bounding stack use.
> > 
> > Fixes: 5faa1f4cb5a1 ("[NETFILTER]: nf_conntrack_netlink: add support to related connections")
> > Cc: stable@vger.kernel.org
> > Link: https://patch.msgid.link/179127347858.434549.11821822167265441355@kernel.org
> > Assisted-by: LLM
> > Signed-off-by: Daehyeon Ko <4ncienth@gmail.com>
> 
> Acked-by: Florian Westphal <fw@strlen.de>
> 
> That said, ignoring the source of the problem is not good.
> 
> I see no point whatsoever for a expected connection to have a
> non-control connection as its master.

I would prefer if chain length is limited too, ie. tighten this
interface based on the LLM feedback.

Re: [PATCH net v3] netfilter: conntrack: avoid recursive master destruction

[Florian Westphal]

Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > That said, ignoring the source of the problem is not good.
> > 
> > I see no point whatsoever for a expected connection to have a
> > non-control connection as its master.
> 
> I would prefer if chain length is limited too, ie. tighten this
> interface based on the LLM feedback.

Thanks, working on this now.  Tentative plan:

#define NF_CT_MAX_EXPECT_CHAIN_LEN     4

static inline bool nf_ct_master_acceptable(const struct nf_conn *m)
{
       unsigned int depth = 0;

       while (m->master) {
               if (++depth > NF_CT_MAX_EXPECT_CHAIN_LEN)
                       return false;
               m = m->master;
       }

       return true;
}

 struct nf_conntrack_expect *nf_ct_expect_alloc(struct nf_conn *me)
 {
        struct nf_conntrack_expect *new;
 
+       if (!nf_ct_master_acceptable(me))
+               return NULL;
+

I'll make an independent submission for this.

Re: [PATCH net v3] netfilter: conntrack: avoid recursive master destruction

[Pablo Neira Ayuso]

On Wed, Oct 07, 2026 at 01:26:27PM +0200, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > > That said, ignoring the source of the problem is not good.
> > > 
> > > I see no point whatsoever for a expected connection to have a
> > > non-control connection as its master.
> > 
> > I would prefer if chain length is limited too, ie. tighten this
> > interface based on the LLM feedback.
> 
> Thanks, working on this now.  Tentative plan:
> 
> #define NF_CT_MAX_EXPECT_CHAIN_LEN     4

4 is a reasonable number, but I think 2 is just enough, which is what
H.323 and SIP need, in case you consider tightening this even further
Userspace helpers are simple, they don't use this feature. It is true
that conntrackd needs this feature for flow synchronization as the LLM
suggests.

> static inline bool nf_ct_master_acceptable(const struct nf_conn *m)
> {
>        unsigned int depth = 0;
> 
>        while (m->master) {
>                if (++depth > NF_CT_MAX_EXPECT_CHAIN_LEN)
>                        return false;
>                m = m->master;
>        }
> 
>        return true;
> }
> 
>  struct nf_conntrack_expect *nf_ct_expect_alloc(struct nf_conn *me)
>  {
>         struct nf_conntrack_expect *new;
>  
> +       if (!nf_ct_master_acceptable(me))
> +               return NULL;
> +
> 
> I'll make an independent submission for this.

Thanks Florian.