Please apply 98d0912e9f84 ("net: skbuff: fix missing zerocopy reference in pskb_carve helpers") to 6.1.y

Please apply 98d0912e9f84 ("net: skbuff: fix missing zerocopy reference in pskb_carve helpers") to 6.1.y

[Salvatore Bonaccorso]

Hi

98d0912e9f84 ("net: skbuff: fix missing zerocopy reference in
pskb_carve helpers") was marked to be backported to stable, but AFAICS
there is a small context issue, to make it apply cleanly.

With adjusting context the change applies, proposed change below.

Does that looks good, and can you pick up the change as well for the
6.1.y series?

Regards,
Salvatore

From b1c88a1281e42a82958d802aaf82026253858b95 Mon Sep 17 00:00:00 2001
From: Minh Nguyen <minhnguyen.080505@gmail.com>
Date: Tue, 26 May 2026 11:12:39 +0700
Subject: [PATCH] net: skbuff: fix missing zerocopy reference in pskb_carve
 helpers

commit 98d0912e9f841e5529a5b89a972805f34cb1c69d upstream.

pskb_carve_inside_header() and pskb_carve_inside_nonlinear() both copy
the old skb_shared_info header into a new buffer via memcpy(), which
includes the destructor_arg pointer (uarg) for MSG_ZEROCOPY skbs.
Neither function calls net_zcopy_get() for the new shinfo, creating an
unaccounted holder: every skb_shared_info with destructor_arg set will
call skb_zcopy_clear() once when freed, but the corresponding
net_zcopy_get() was never called for the new copy. Repeated calls
drive uarg->refcnt to zero prematurely, freeing ubuf_info_msgzc while
TX skbs still hold live destructor_arg pointers.

KASAN reports use-after-free on a freed ubuf_info_msgzc:

  BUG: KASAN: slab-use-after-free in skb_release_data+0x77b/0x810
  Read of size 8 at addr ffff88801574d3e8 by task poc/220

  Call Trace:
   skb_release_data+0x77b/0x810
   kfree_skb_list_reason+0x13e/0x610
   skb_release_data+0x4cd/0x810
   sk_skb_reason_drop+0xf3/0x340
   skb_queue_purge_reason+0x282/0x440
   rds_tcp_inc_free+0x1e/0x30
   rds_recvmsg+0x354/0x1780
   __sys_recvmsg+0xdf/0x180

  Allocated by task 219:
   msg_zerocopy_realloc+0x157/0x7b0
   tcp_sendmsg_locked+0x2892/0x3ba0

  Freed by task 219:
   ip_recv_error+0x74a/0xb10
   tcp_recvmsg+0x475/0x530

The skb consuming the late access still referenced the same uarg via
shinfo->destructor_arg copied by pskb_carve_inside_nonlinear() without
a refcount bump. This has been verified to be reliably exploitable: a
working proof-of-concept achieves full root privilege escalation from
an unprivileged local user on a default kernel configuration.

The fix follows the pattern of pskb_expand_head() which has the same
memcpy/cloned structure. For pskb_carve_inside_header(), net_zcopy_get()
is placed after skb_orphan_frags() succeeds, so the orphan error path
needs no cleanup. For pskb_carve_inside_nonlinear(), net_zcopy_get() is
placed after all failure points and just before skb_release_data(), so
no error path needs cleanup at all -- matching pskb_expand_head() more
closely and avoiding the need for a balancing net_zcopy_put().

Fixes: 6fa01ccd8830 ("skbuff: Add pskb_extract() helper function")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-sonnet-4-6
Signed-off-by: Minh Nguyen <minhnguyen.080505@gmail.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Link: https://patch.msgid.link/20260526041240.329462-1-minhnguyen.080505@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
[Salvatore Bonaccorso: Backport for context changes, as 6.1.y has not
511a3eda2f8d ("net: dropreason: propagate drop_reason to
skb_release_data()")].
Signed-off-by: Salvatore Bonaccorso <carnil@debian.org>
---
 net/core/skbuff.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 8bc4b26de5e5..b91e2e9f1096 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -6242,6 +6242,8 @@ static int pskb_carve_inside_header(struct sk_buff *skb, const u32 off,
 			kfree(data);
 			return -ENOMEM;
 		}
+		if (skb_zcopy(skb))
+			net_zcopy_get(skb_zcopy(skb));
 		for (i = 0; i < skb_shinfo(skb)->nr_frags; i++)
 			skb_frag_ref(skb, i);
 		if (skb_has_frag_list(skb))
@@ -6386,6 +6388,8 @@ static int pskb_carve_inside_nonlinear(struct sk_buff *skb, const u32 off,
 		kfree(data);
 		return -ENOMEM;
 	}
+	if (skb_zcopy(skb))
+		net_zcopy_get(skb_zcopy(skb));
 	skb_release_data(skb);
 
 	skb->head = data;
-- 
2.53.0

Re: Please apply 98d0912e9f84 ("net: skbuff: fix missing zerocopy reference in pskb_carve helpers") to 6.1.y

[Sasha Levin]

On Mon, Jun 09, 2026 at 09:16:35PM +0200, Salvatore Bonaccorso wrote:
> Please apply 98d0912e9f84 ("net: skbuff: fix missing zerocopy
> reference in pskb_carve helpers") to 6.1.y

Agreed this is needed. It's already queued in the newer trees (7.0,
6.18 and 6.12 all carry it), but 6.6, 6.1, 5.15 and 5.10 are all
affected and still missing it.

--
Thanks,
Sasha

Re: Please apply 98d0912e9f84 ("net: skbuff: fix missing zerocopy reference in pskb_carve helpers") to 6.1.y

[Salvatore Bonaccorso]

Hi Sasha,

On Wed, Jun 10, 2026 at 08:45:25PM -0400, Sasha Levin wrote:
> On Mon, Jun 09, 2026 at 09:16:35PM +0200, Salvatore Bonaccorso wrote:
> > Please apply 98d0912e9f84 ("net: skbuff: fix missing zerocopy
> > reference in pskb_carve helpers") to 6.1.y
> 
> Agreed this is needed. It's already queued in the newer trees (7.0,
> 6.18 and 6.12 all carry it), but 6.6, 6.1, 5.15 and 5.10 are all
> affected and still missing it.

Yes I know that, sorry my wording in the backport request was not
quite optimal to understand. I knew it was already included in 7.0.12,
6.18.35 and 6.12.93. When looking why it was not picked for the older
series I noticed might just have been the context change, which I
tested down to 6.1.y and proposed the adjusted backported commit.

I realize that the commit for 6.6.y needs to be as well slightly
different.

What I have *not* done was to test if it goes clean as well back to
5.15 and 5.10. It will need likely more work as there is no
net_zcopy_get() in 5.10.y.

Sasha, do you want me to send as well an explicit 6.6.y one? Or will
you pick the change already for 6.6.y and 6.1.y? 

Regards,
Salvatore

Re: Please apply 98d0912e9f84 ("net: skbuff: fix missing zerocopy reference in pskb_carve helpers") to 6.1.y

[Sasha Levin]

On Thu, Jun 11, 2026 at 05:59:52AM +0200, Salvatore Bonaccorso wrote:
> I tested down to 6.1.y; the 6.6.y commit needs to be slightly
> different. I have not tested 5.15/5.10 (no net_zcopy_get() in 5.10.y,
> so more work there). Should I send an explicit 6.6.y patch, or will
> you pick the change for 6.6.y and 6.1.y yourself?

Your 6.1.y patch applies cleanly and looks correct. But I can't queue it
on its own: 98d0912e9f84 isn't in 6.6.y yet, and I don't add a fix to an
older tree while a newer one is missing it. So I'm holding the 6.1.y
change until 6.6.y is sorted.

Rather than have me hand-adapt the other trees, please send explicit
per-branch backports: your 6.1 patch doesn't apply cleanly to 6.6.y

--
Thanks,
Sasha

Re: Please apply 98d0912e9f84 ("net: skbuff: fix missing zerocopy reference in pskb_carve helpers") down to 6.1.y

[Salvatore Bonaccorso]

Hi Sasha,

On Thu, Jun 11, 2026 at 11:26:23AM -0400, Sasha Levin wrote:
> On Thu, Jun 11, 2026 at 05:59:52AM +0200, Salvatore Bonaccorso wrote:
> > I tested down to 6.1.y; the 6.6.y commit needs to be slightly
> > different. I have not tested 5.15/5.10 (no net_zcopy_get() in 5.10.y,
> > so more work there). Should I send an explicit 6.6.y patch, or will
> > you pick the change for 6.6.y and 6.1.y yourself?
> 
> Your 6.1.y patch applies cleanly and looks correct. But I can't queue it
> on its own: 98d0912e9f84 isn't in 6.6.y yet, and I don't add a fix to an
> older tree while a newer one is missing it. So I'm holding the 6.1.y
> change until 6.6.y is sorted.

Yes this is right, and is my bad that I did not spot the slight
context change in the 6.6.y version. I'm very well awaere of the
policy of the top down applying the patches and fully aknowledge that
the 6.1.y one should only be applied if the 6.6.y one is applied as
well. 

> Rather than have me hand-adapt the other trees, please send explicit
> per-branch backports: your 6.1 patch doesn't apply cleanly to 6.6.y

Here is the backport for the 6.6.y series as well.

As mentioned in the other mail, I could not have looked explicitly for
the 5.15.y and 5.10.y. In particular for the later I think more work
is required.

Thanks for your work!

Regards,
Salvatore

From e1829fcaea02ca81a047c1583a9767b325e1470b Mon Sep 17 00:00:00 2001
From: Minh Nguyen <minhnguyen.080505@gmail.com>
Date: Tue, 26 May 2026 11:12:39 +0700
Subject: [PATCH] net: skbuff: fix missing zerocopy reference in pskb_carve
 helpers

commit 98d0912e9f841e5529a5b89a972805f34cb1c69d upstream.

pskb_carve_inside_header() and pskb_carve_inside_nonlinear() both copy
the old skb_shared_info header into a new buffer via memcpy(), which
includes the destructor_arg pointer (uarg) for MSG_ZEROCOPY skbs.
Neither function calls net_zcopy_get() for the new shinfo, creating an
unaccounted holder: every skb_shared_info with destructor_arg set will
call skb_zcopy_clear() once when freed, but the corresponding
net_zcopy_get() was never called for the new copy. Repeated calls
drive uarg->refcnt to zero prematurely, freeing ubuf_info_msgzc while
TX skbs still hold live destructor_arg pointers.

KASAN reports use-after-free on a freed ubuf_info_msgzc:

  BUG: KASAN: slab-use-after-free in skb_release_data+0x77b/0x810
  Read of size 8 at addr ffff88801574d3e8 by task poc/220

  Call Trace:
   skb_release_data+0x77b/0x810
   kfree_skb_list_reason+0x13e/0x610
   skb_release_data+0x4cd/0x810
   sk_skb_reason_drop+0xf3/0x340
   skb_queue_purge_reason+0x282/0x440
   rds_tcp_inc_free+0x1e/0x30
   rds_recvmsg+0x354/0x1780
   __sys_recvmsg+0xdf/0x180

  Allocated by task 219:
   msg_zerocopy_realloc+0x157/0x7b0
   tcp_sendmsg_locked+0x2892/0x3ba0

  Freed by task 219:
   ip_recv_error+0x74a/0xb10
   tcp_recvmsg+0x475/0x530

The skb consuming the late access still referenced the same uarg via
shinfo->destructor_arg copied by pskb_carve_inside_nonlinear() without
a refcount bump. This has been verified to be reliably exploitable: a
working proof-of-concept achieves full root privilege escalation from
an unprivileged local user on a default kernel configuration.

The fix follows the pattern of pskb_expand_head() which has the same
memcpy/cloned structure. For pskb_carve_inside_header(), net_zcopy_get()
is placed after skb_orphan_frags() succeeds, so the orphan error path
needs no cleanup. For pskb_carve_inside_nonlinear(), net_zcopy_get() is
placed after all failure points and just before skb_release_data(), so
no error path needs cleanup at all -- matching pskb_expand_head() more
closely and avoiding the need for a balancing net_zcopy_put().

Fixes: 6fa01ccd8830 ("skbuff: Add pskb_extract() helper function")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-sonnet-4-6
Signed-off-by: Minh Nguyen <minhnguyen.080505@gmail.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Link: https://patch.msgid.link/20260526041240.329462-1-minhnguyen.080505@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
[Salvatore Bonaccorso: Adjust for context changes in v6.6.y]
Signed-off-by: Salvatore Bonaccorso <carnil@debian.org>
---
 net/core/skbuff.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 8b05866e93b1..b901e6ff461e 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -6407,6 +6407,8 @@ static int pskb_carve_inside_header(struct sk_buff *skb, const u32 off,
 			skb_kfree_head(data, size);
 			return -ENOMEM;
 		}
+		if (skb_zcopy(skb))
+			net_zcopy_get(skb_zcopy(skb));
 		for (i = 0; i < skb_shinfo(skb)->nr_frags; i++)
 			skb_frag_ref(skb, i);
 		if (skb_has_frag_list(skb))
@@ -6551,6 +6553,8 @@ static int pskb_carve_inside_nonlinear(struct sk_buff *skb, const u32 off,
 		skb_kfree_head(data, size);
 		return -ENOMEM;
 	}
+	if (skb_zcopy(skb))
+		net_zcopy_get(skb_zcopy(skb));
 	skb_release_data(skb, SKB_CONSUMED, false);
 
 	skb->head = data;
-- 
2.53.0

Re: Please apply 98d0912e9f84 ("net: skbuff: fix missing zerocopy reference in pskb_carve helpers") down to 6.1.y

[Sasha Levin]

On Thu, Jun 11, 2026 at 06:29:37PM +0200, Salvatore Bonaccorso wrote:
> Here is the backport for the 6.6.y series as well.
>
> As mentioned in the other mail, I could not have looked explicitly for
> the 5.15.y and 5.10.y. In particular for the later I think more work
> is required.

Thanks, queued for 6.6.y and 6.1.y.

--
Thanks,
Sasha

Re: Please apply 98d0912e9f84 ("net: skbuff: fix missing zerocopy reference in pskb_carve helpers") down to 6.1.y

[Sasha Levin]

On Thu, Jun 11, 2026 at 06:29:37PM +0200, Salvatore Bonaccorso wrote:
> Here is the backport for the 6.6.y series as well.
>
> As mentioned in the other mail, I could not have looked explicitly for
> the 5.15.y and 5.10.y. In particular for the later I think more work
> is required.

Thanks, the 6.6.y backport is queued, and 6.1.y is queued on top of it.

--
Thanks,
Sasha