Re: [PATCH 2/8] esp: do not unref managed frag pages in esp_ssg_unref()

[Steffen Klassert <steffen.klassert@secunet.com>]

Maher, please look at this review of your patch.

Thanks!

On Thu, Jul 30, 2026 at 07:15:44PM -0700, Jakub Kicinski wrote:
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> ---
> --- Patch [2]: [PATCH 2/8] esp: do not unref managed frag pages in esp_ssg_unref() ---
> commit 1913e3a658480a2d9a14804dfb34715f589f403d
> Author: Maher Azzouzi <maherazz04@gmail.com>
> 
> esp: do not unref managed frag pages in esp_ssg_unref()
> 
> The patch adds an early return to esp_ssg_unref() in both esp4.c and esp6.c
> so that no per-frag page reference is dropped when the skb carries managed
> frags (SKBFL_MANAGED_FRAG_REFS), mirroring the skip_unref handling in
> skb_release_data().
> 
> A couple of questions on the commit message and on the scope of the guard.
> 
> >     Fixes: cac2661c53f3 ("esp4: Avoid skb_cow_data whenever possible")
> >     Fixes: 03e2a30f6a27 ("esp6: Avoid skb_cow_data whenever possible")
> 
> [Severity: Medium]
> [Finding: main-1-2]
> [Sources: opus-5]
> 
> Are these the right commits to blame?  Both are dated 2017-01-17, while
> SKBFL_MANAGED_FRAG_REFS and the skb_zcopy_managed() helper used by the new
> guard only arrived with 753f1ca4e1e5 ("net: introduce managed frags
> infrastructure", 2022-07-12, v6.1).
> 
> The esp code as written in 2017 had nothing to be wrong about here; the
> described scenario only becomes possible once managed-frag skbs can reach
> the xfrm output path.
> 
> Since Fixes: tags drive stable and AUTOSEL selection, this points the patch
> at trees older than v6.1, where skb_zcopy_managed() does not exist at all
> (build failure) and where the described scenario cannot happen.  Would the
> commit that made managed-frag skbs reachable from esp_output() be the better
> blame target, or no Fixes: tag plus an explicit stable range?
> 
> > diff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c
> > index dfc81ee969ae0..fa1710e27e505 100644
> > --- a/net/ipv4/esp4.c
> > +++ b/net/ipv4/esp4.c
> > @@ -104,6 +104,13 @@ static void esp_ssg_unref(struct xfrm_state *x, void *tmp, struct sk_buff *skb,
> >  	struct aead_request *req;
> >  	struct scatterlist *sg;
> >  
> > +	/* Managed frags are owned by the zerocopy ubuf; the skb holds no
> > +	 * per-frag page reference, so we must not drop one here.  Mirrors
> > +	 * the SKBFL_MANAGED_FRAG_REFS handling in skb_release_data().
> > +	 */
> > +	if (skb_zcopy_managed(skb))
> > +		return;
> > +
> 
> [Severity: High]
> [Finding: main-1-0]
> [Sources: opus-5]
> 
> Does this early return also suppress the release of the trailer page that
> ESP itself referenced?
> 
> The src scatterlist looks like it has mixed ownership.  Besides the
> ubuf-owned payload frags, esp_output_head() adds a trailer frag with an
> explicit reference in the only branch that sets esp->inplace = false:
> 
> net/ipv4/esp4.c:esp_output_head() {
> 	...
> 			page = pfrag->page;
> 			get_page(page);
> 	...
> 			__skb_fill_page_desc(skb, nfrags, page, pfrag->offset,
> 					     tailen);
> 			skb_shinfo(skb)->nr_frags = ++nfrags;
> 	...
> }
> 
> esp_output_tail() then drops that frag from the skb entirely:
> 
> net/ipv4/esp4.c:esp_output_tail() {
> 	...
> 		skb_shinfo(skb)->nr_frags = 1;
> 
> 		page = pfrag->page;
> 		get_page(page);
> 		/* replace page frags in skb with new page */
> 		__skb_fill_page_desc(skb, 0, page, pfrag->offset, skb->data_len);
> 	...
> }
> 
> so the loop in esp_ssg_unref() appears to be the only remaining release
> site for that trailer reference.  skb_release_data() cannot reach the
> orphaned frag, and for SKBFL_MANAGED_FRAG_REFS it takes the skip_unref
> branch to free_head anyway.
> 
> Both esp_ssg_unref() call sites in esp_output_tail() are affected: the error
> path
> 
> 		if (unlikely(err < 0)) {
> 			esp_ssg_unref(x, tmp, skb, true);
> 
> and the success path
> 
> 	if (sg != dsg)
> 		esp_ssg_unref(x, tmp, skb, false);
> 
> Note the loop only ever ran in exactly that non-inplace case
> (already_unref || req->src != req->dst), which is also the case that adds
> the trailer frag.  So does the get_page() from esp_output_head() stay
> unbalanced for a managed-frag skb?
> 
> Since a single stray reference pins the whole high-order x->xfrag
> page_frag page, would every x->xfrag page used for trailers become
> unfreeable, at packet rate?
> 
> Would it be better to distinguish ubuf-owned frags from the ESP-added
> trailer frag, for instance by calling skb_zcopy_downgrade_managed(skb)
> before ESP mutates the frag array, the way __ip_append_data() and
> __ip6_append_data() do, rather than skipping the unref wholesale?
> 
> Related to that, the new comment says "the skb holds no per-frag page
> reference".  Is that accurate?  It holds true for the ubuf-owned frags, but
> not for the trailer frag ESP added with get_page().
> 
> [Severity: High]
> [Finding: main-1-1]
> [Sources: opus-5]
> 
> This isn't a bug introduced by this patch, but it is the invariant the
> guard works around, and it stays unfixed: esp_output_tail() replaces the
> frag array of a managed-frag skb with a page it references itself, while
> SKBFL_MANAGED_FRAG_REFS remains set:
> 
> net/ipv4/esp4.c:esp_output_tail() {
> 	...
> 		skb_shinfo(skb)->nr_frags = 1;
> 
> 		page = pfrag->page;
> 		get_page(page);
> 		/* replace page frags in skb with new page */
> 		__skb_fill_page_desc(skb, 0, page, pfrag->offset, skb->data_len);
> 	...
> }
> 
> That destination page reference is owned by frag 0, but with the flag still
> set skb_release_data() takes the skip_unref branch:
> 
> net/core/skbuff.c:skb_release_data() {
> 	...
> 	if (skb_zcopy(skb)) {
> 		bool skip_unref = shinfo->flags & SKBFL_MANAGED_FRAG_REFS;
> 
> 		skb_zcopy_clear(skb, true);
> 		if (skip_unref)
> 			goto free_head;
> 	}
> 	...
> }
> 
> so is that reference ever dropped?  Neither net/ipv4/esp4.c nor
> net/ipv6/esp6.c calls skb_zcopy_downgrade_managed(); the canonical way to
> make a managed-frag skb safe for frag mutation and per-frag unref is:
> 
> net/core/skbuff.c:__skb_zcopy_downgrade_managed() {
> 	skb_shinfo(skb)->flags &= ~SKBFL_MANAGED_FRAG_REFS;
> 	for (i = 0; i < skb_shinfo(skb)->nr_frags; i++)
> 		skb_frag_ref(skb, i);
> }
> 
> which every other frag-mutating site uses (net/core/skbuff.c,
> net/ipv4/ip_output.c, net/ipv6/ip6_output.c, net/ipv4/tcp.c).
> 
> Would a single skb_zcopy_downgrade_managed(skb) before ESP touches the
> frags address both the original refcount underflow and this leak, instead
> of leaving a mixed managed/refcounted frag array as an ESP-specific special
> case?  In that light, is the commit message statement "The rest of the
> stack honours this invariant" only half applied here?
> 
> >  	if (x->props.flags & XFRM_STATE_ESN)
> >  		extralen += sizeof(struct esp_output_extra);
> >  
> > diff --git a/net/ipv6/esp6.c b/net/ipv6/esp6.c
> > index 296b57926abb9..7d216b9c59f04 100644
> > --- a/net/ipv6/esp6.c
> > +++ b/net/ipv6/esp6.c
> > @@ -121,6 +121,13 @@ static void esp_ssg_unref(struct xfrm_state *x, void *tmp, struct sk_buff *skb,
> >  	struct aead_request *req;
> >  	struct scatterlist *sg;
> >  
> > +	/* Managed frags are owned by the zerocopy ubuf; the skb holds no
> > +	 * per-frag page reference, so we must not drop one here.  Mirrors
> > +	 * the SKBFL_MANAGED_FRAG_REFS handling in skb_release_data().
> > +	 */
> > +	if (skb_zcopy_managed(skb))
> > +		return;
> > +
> 
> [Severity: High]
> [Finding: main-1-0]
> [Sources: opus-5]
> 
> Do both questions above apply identically to the IPv6 copy?
> esp6_output_head() takes the same get_page() for the trailer frag,
> esp6_output_tail() performs the same nr_frags = 1 frag replacement, and both
> esp_ssg_unref() calls (already_unref == true in the skb_to_sgvec() error
> path, and the sg != dsg call after encryption) return early here too.
> 
> >  	if (x->props.flags & XFRM_STATE_ESN)
> >  		extralen += sizeof(struct esp_output_extra);
> >