[PATCH nf] netfilter: nf_conntrack: Add allow_clash to generic protocol handler

[PATCH nf] netfilter: nf_conntrack: Add allow_clash to generic protocol handler

[Yuto Hamaguchi]

The upstream commit, 71d8c47fc653711c41bc3282e5b0e605b3727956
 ("netfilter: conntrack: introduce clash resolution on insertion race"),
sets allow_clash=true in the UDP/UDPLITE protocol handler
but does not set it in the generic protocol handler.

As a result, packets composed of connectionless protocols at each layer,
such as UDP over IP-in-IP, still drop packets due to conflicts during conntrack insertion.

To resolve this, this patch sets allow_clash in the nf_conntrack_l4proto_generic.

Signed-off-by: Yuto Hamaguchi <Hamaguchi.Yuto@da.MitsubishiElectric.co.jp>
---
 net/netfilter/nf_conntrack_proto_generic.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/netfilter/nf_conntrack_proto_generic.c b/net/netfilter/nf_conntrack_proto_generic.c
index e831637bc8ca..cb260eb3d012 100644
--- a/net/netfilter/nf_conntrack_proto_generic.c
+++ b/net/netfilter/nf_conntrack_proto_generic.c
@@ -67,6 +67,7 @@ void nf_conntrack_generic_init_net(struct net *net)
 const struct nf_conntrack_l4proto nf_conntrack_l4proto_generic =
 {
 	.l4proto		= 255,
+	.allow_clash            = true,
 #ifdef CONFIG_NF_CONNTRACK_TIMEOUT
 	.ctnl_timeout		= {
 		.nlattr_to_obj	= generic_timeout_nlattr_to_obj,
-- 
2.36.1

Re: [PATCH nf] netfilter: nf_conntrack: Add allow_clash to generic protocol handler

[Florian Westphal]

Yuto Hamaguchi <Hamaguchi.Yuto@da.MitsubishiElectric.co.jp> wrote:
> The upstream commit, 71d8c47fc653711c41bc3282e5b0e605b3727956
>  ("netfilter: conntrack: introduce clash resolution on insertion race"),
> sets allow_clash=true in the UDP/UDPLITE protocol handler
> but does not set it in the generic protocol handler.
> 
> As a result, packets composed of connectionless protocols at each layer,
> such as UDP over IP-in-IP, still drop packets due to conflicts during conntrack insertion.
> 
> To resolve this, this patch sets allow_clash in the nf_conntrack_l4proto_generic.

Makes sense to me, thanks.
I'll apply this for the next batch.

Re: [PATCH nf] netfilter: nf_conntrack: Add allow_clash to generic protocol handler

[Pablo Neira Ayuso]

On Sat, Dec 20, 2025 at 09:05:59PM +0100, Florian Westphal wrote:
> Yuto Hamaguchi <Hamaguchi.Yuto@da.MitsubishiElectric.co.jp> wrote:
> > The upstream commit, 71d8c47fc653711c41bc3282e5b0e605b3727956
> >  ("netfilter: conntrack: introduce clash resolution on insertion race"),
> > sets allow_clash=true in the UDP/UDPLITE protocol handler
> > but does not set it in the generic protocol handler.
> > 
> > As a result, packets composed of connectionless protocols at each layer,
> > such as UDP over IP-in-IP, still drop packets due to conflicts during conntrack insertion.
> > 
> > To resolve this, this patch sets allow_clash in the nf_conntrack_l4proto_generic.
> 
> Makes sense to me, thanks.

Would it be possible to follow a more conservative approach?
ie. restrict this to protocols where we know clashes are possible
such as IPIP.

Re: [PATCH nf] netfilter: nf_conntrack: Add allow_clash to generic protocol handler

[Florian Westphal]

Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> On Sat, Dec 20, 2025 at 09:05:59PM +0100, Florian Westphal wrote:
> > Yuto Hamaguchi <Hamaguchi.Yuto@da.MitsubishiElectric.co.jp> wrote:
> > > The upstream commit, 71d8c47fc653711c41bc3282e5b0e605b3727956
> > >  ("netfilter: conntrack: introduce clash resolution on insertion race"),
> > > sets allow_clash=true in the UDP/UDPLITE protocol handler
> > > but does not set it in the generic protocol handler.
> > > 
> > > As a result, packets composed of connectionless protocols at each layer,
> > > such as UDP over IP-in-IP, still drop packets due to conflicts during conntrack insertion.
> > > 
> > > To resolve this, this patch sets allow_clash in the nf_conntrack_l4proto_generic.
> > 
> > Makes sense to me, thanks.
> 
> Would it be possible to follow a more conservative approach?
> ie. restrict this to protocols where we know clashes are possible
> such as IPIP.

I don't think there is a need to be more conservative here.

If we have to fallback to the generic tracker that means we don't have a
L4 aware tracker for the protocol, so we can always merge entries instead
of dropping them.

Whats the concern?