Re: [PATCH 0/10] pull request (net): ipsec 2026-08-18

[Paolo Abeni <pabeni@redhat.com>]

Hi Steffen!

On 8/18/26 11:28 AM, Steffen Klassert wrote:
> 1) xfrm6: fix out-of-bounds write in xfrm6_input_addr() when secpath is full
>    Tighten the secpath-depth check so a full chain can't write
>    past xvec[].
> 
> 2) Add and revert "esp: do not unref managed frag pages in esp_ssg_unref()"
>    The patch does not fully fully resolve the issue, a corrected version
>    will follow.
> 
> 3) xfrm: espintcp: fix UAF during close
>    Synchronize espintcp close with the xfrm_trans_reinject work
>    queue so the freed socket message isn't dereferenced again.
> 
> 4) xfrm: drop ESP-in-TCP packets with no ingress device
>    Drop queued ESP-in-TCP records whose saved ingress device has
>    gone away, avoiding a NULL device deref in the XFRM input path.
> 
> 5) xfrm: avoid lock inversion in nat keepalive work
>    Split the NAT keepalive walk into a reference-collection phase
>    and a per-state lock phase to break the AB-BA with state removal.
>    This patch has some issues that are fixed with a followup patch.
> 
> 6) xfrm: Fix skb double-free in xfrm_dev_direct_output()
>    Stop freeing the skb unconditionally in xfrm_dev_direct_output(),
>    letting local_out()'s result indicate when ownership has moved on.
> 
> 7) xfrm: ah6: validate routing header segments_left
>    Validate the segments_left/hdrlen invariant before rearranging
>    the routing-header addresses, avoiding an OOB memmove on
>    malformed HDRINCL packets.
> 
> 8) xfrm: fix xfrm_state_construct() auth-trunc leak
>    Detect an already-attached auth-trunc allocation by the pointer
>    rather than inferring it from the algorithm id, so a prior
>    attach isn't overwritten and lost.
> 
> 9) xfrm: bound nat keepalive state collection
>    Replace the per-state allocation in the NAT keepalive walk
>    with a fixed-size batch that drains under BH-disabled locking
>    and resumes from the cursor, bounding the worker's memory.
> 
> Please pull or let me know if there are problems.
Sashiko has a few comments:

https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260818092920.653034-1-steffen.klassert%40secunet.com

do you think they deserve a v2 or could be handled as follow-ups?

Also the fixes tag in patch 10/10 looks invalid. Possibly a rebase
would be needed?

Thanks,

Paolo