Subject: Re: [PATCH 20/20] xfrm: iptfs: only publish mode_data after clone setup

From: Steffen Klassert <[email-masked]>
Date: Tue, 24 Mar 2026 13:40:51 +0100

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 <[email-masked]>
> >>>
> >>> 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: [email-masked]
> >>> Signed-off-by: Paul Moses <[email-masked]>
> >>> Signed-off-by: Steffen Klassert <[email-masked]>
> >>
> >> 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.