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

[Paolo Abeni <pabeni@redhat.com>]

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.

/P