From: Steffen Klassert <steffen.klassert@secunet.com>
To: Paolo Abeni <pabeni@redhat.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
<netdev@vger.kernel.org>, David Miller <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>
Subject: Re: [PATCH 20/20] xfrm: iptfs: only publish mode_data after clone setup
Date: Tue, 24 Mar 2026 13:40:51 +0100 [thread overview]
Message-ID: <acKGU5rF-yH2LI7v@secunet.com> (raw)
In-Reply-To: <75af5781-0ed2-4b05-879f-db6628af0692@redhat.com>
On Tue, Mar 24, 2026 at 01:35:25PM +0100, Paolo Abeni wrote:
> On 3/24/26 12:52 PM, Steffen Klassert wrote:
> > On Tue, Mar 24, 2026 at 12:33:15PM +0100, Paolo Abeni wrote:
> >> On 3/23/26 9:34 AM, Steffen Klassert wrote:
> >>> From: Paul Moses <p@1g4.org>
> >>>
> >>> iptfs_clone_state() stores x->mode_data before allocating the reorder
> >>> window. If that allocation fails, the code frees the cloned state and
> >>> returns -ENOMEM, leaving x->mode_data pointing at freed memory.
> >>>
> >>> The xfrm clone unwind later runs destroy_state() through x->mode_data,
> >>> so the failed clone path tears down IPTFS state that clone_state()
> >>> already freed.
> >>>
> >>> Keep the cloned IPTFS state private until all allocations succeed so
> >>> failed clones leave x->mode_data unset. The destroy path already
> >>> handles a NULL mode_data pointer.
> >>>
> >>> Fixes: 6be02e3e4f37 ("xfrm: iptfs: handle reordering of received packets")
> >>> Cc: stable@vger.kernel.org
> >>> Signed-off-by: Paul Moses <p@1g4.org>
> >>> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
> >>
> >> While applying this series to verify the PR, I get the following error:
> >>
> >> Applying: xfrm: iptfs: only publish mode_data after clone setup
> >> error: sha1 information is lacking or useless (net/xfrm/xfrm_iptfs.c).
> >> error: could not build fake ancestor
> >> Patch failed at 0020 xfrm: iptfs: only publish mode_data after clone setup
> >>
> >> The above also prevents the CI from testing the series. Steffen, could
> >> you please have a look? Possibly a repost could be needed.
> >
> > I guess this is due to a merge conflict with:
> >
> > 69050f8d6d07 ("treewide: Replace kmalloc with kmalloc_obj for non-scalar types")
> >
> > Repost will not help in that case. Not sure what to do
> > here. The only thing that would fix it is a forced rebase
> > of the ipsec tree onto the net tree.
>
> Out of blatant naiveness on my side, how much of a pain would be that
> option? If more than negligible, I guess we should avoid it.
It is some work on my side, but the bigger problem is for
those who cloned my ipsec tree. They all need to do this
forced rebase then. This will hit them by surprise then.
So IMO, if we can avoid it, we should better not rebase.
next prev parent reply other threads:[~2026-03-24 12:40 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-23 8:33 [PATCH 0/20] pull request (net): ipsec 2026-03-23 Steffen Klassert
2026-03-23 8:33 ` [PATCH 01/20] xfrm: add missing extack for XFRMA_SA_PCPU in add_acquire and allocspi Steffen Klassert
2026-03-24 14:30 ` patchwork-bot+netdevbpf
2026-03-23 8:33 ` [PATCH 02/20] xfrm: fix the condition on x->pcpu_num in xfrm_sa_len Steffen Klassert
2026-03-23 8:33 ` [PATCH 03/20] xfrm: call xdo_dev_state_delete during state update Steffen Klassert
2026-03-23 8:33 ` [PATCH 04/20] esp: fix skb leak with espintcp and async crypto Steffen Klassert
2026-03-23 8:33 ` [PATCH 05/20] xfrm: iptfs: validate inner IPv4 header length in IPTFS payload Steffen Klassert
2026-03-23 8:33 ` [PATCH 06/20] xfrm: iptfs: fix skb_put() panic on non-linear skb during reassembly Steffen Klassert
2026-03-23 8:33 ` [PATCH 07/20] xfrm: state: fix sparse warnings on xfrm_state_hold_rcu Steffen Klassert
2026-03-23 8:33 ` [PATCH 08/20] xfrm: state: fix sparse warnings in xfrm_state_init Steffen Klassert
2026-03-23 8:33 ` [PATCH 09/20] xfrm: state: fix sparse warnings around XFRM_STATE_INSERT Steffen Klassert
2026-03-23 8:33 ` [PATCH 10/20] xfrm: state: add xfrm_state_deref_prot to state_by* walk under lock Steffen Klassert
2026-03-23 8:33 ` [PATCH 11/20] xfrm: remove rcu/state_hold from xfrm_state_lookup_spi_proto Steffen Klassert
2026-03-23 8:33 ` [PATCH 12/20] xfrm: state: silence sparse warnings during netns exit Steffen Klassert
2026-03-23 8:33 ` [PATCH 13/20] xfrm: policy: fix sparse warnings in xfrm_policy_{init,fini} Steffen Klassert
2026-03-23 8:33 ` [PATCH 14/20] xfrm: policy: silence sparse warning in xfrm_policy_unregister_afinfo Steffen Klassert
2026-03-23 8:33 ` [PATCH 15/20] xfrm: add rcu_access_pointer to silence sparse warning for xfrm_input_afinfo Steffen Klassert
2026-03-23 8:33 ` [PATCH 16/20] xfrm: avoid RCU warnings around the per-netns netlink socket Steffen Klassert
2026-03-23 8:33 ` [PATCH 17/20] xfrm: Fix work re-schedule after cancel in xfrm_nat_keepalive_net_fini() Steffen Klassert
2026-03-23 8:33 ` [PATCH 18/20] xfrm: prevent policy_hthresh.work from racing with netns teardown Steffen Klassert
2026-03-23 8:34 ` [PATCH 19/20] af_key: validate families in pfkey_send_migrate() Steffen Klassert
2026-03-23 8:34 ` [PATCH 20/20] xfrm: iptfs: only publish mode_data after clone setup Steffen Klassert
2026-03-24 11:33 ` Paolo Abeni
2026-03-24 11:52 ` Steffen Klassert
2026-03-24 12:35 ` Paolo Abeni
2026-03-24 12:40 ` Steffen Klassert [this message]
2026-03-24 14:22 ` Paolo Abeni
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=acKGU5rF-yH2LI7v@secunet.com \
--to=steffen.klassert@secunet.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox