FAILED: patch "[PATCH] rxrpc: Fix conn-level packet handling to unshare RESPONSE" failed to apply to 6.6-stable tree

FAILED: patch "[PATCH] rxrpc: Fix conn-level packet handling to unshare RESPONSE" failed to apply to 6.6-stable tree

[gregkh]

The patch below does not apply to the 6.6-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.

To reproduce the conflict and resubmit, you may use the following commands:

git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.6.y
git checkout FETCH_HEAD
git cherry-pick -x 24481a7f573305706054c59e275371f8d0fe919f
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable@vger.kernel.org>' --in-reply-to '2026050141-endearing-facedown-3f88@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^..

Possible dependencies:



thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

From 24481a7f573305706054c59e275371f8d0fe919f Mon Sep 17 00:00:00 2001
From: David Howells <dhowells@redhat.com>
Date: Wed, 22 Apr 2026 17:14:33 +0100
Subject: [PATCH] rxrpc: Fix conn-level packet handling to unshare RESPONSE
 packets

The security operations that verify the RESPONSE packets decrypt bits of it
in place - however, the sk_buff may be shared with a packet sniffer, which
would lead to the sniffer seeing an apparently corrupt packet (actually
decrypted).

Fix this by handing a copy of the packet off to the specific security
handler if the packet was cloned.

Fixes: 17926a79320a ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both")
Closes: https://sashiko.dev/#/patchset/20260408121252.2249051-1-dhowells%40redhat.com
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Marc Dionne <marc.dionne@auristor.com>
cc: Jeffrey Altman <jaltman@auristor.com>
cc: Simon Horman <horms@kernel.org>
cc: linux-afs@lists.infradead.org
cc: stable@kernel.org
Link: https://patch.msgid.link/20260422161438.2593376-5-dhowells@redhat.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

diff --git a/net/rxrpc/conn_event.c b/net/rxrpc/conn_event.c
index 9a41ec708aeb..aee977291d90 100644
--- a/net/rxrpc/conn_event.c
+++ b/net/rxrpc/conn_event.c
@@ -240,6 +240,33 @@ static void rxrpc_call_is_secure(struct rxrpc_call *call)
 		rxrpc_notify_socket(call);
 }
 
+static int rxrpc_verify_response(struct rxrpc_connection *conn,
+				 struct sk_buff *skb)
+{
+	int ret;
+
+	if (skb_cloned(skb)) {
+		/* Copy the packet if shared so that we can do in-place
+		 * decryption.
+		 */
+		struct sk_buff *nskb = skb_copy(skb, GFP_NOFS);
+
+		if (nskb) {
+			rxrpc_new_skb(nskb, rxrpc_skb_new_unshared);
+			ret = conn->security->verify_response(conn, nskb);
+			rxrpc_free_skb(nskb, rxrpc_skb_put_response_copy);
+		} else {
+			/* OOM - Drop the packet. */
+			rxrpc_see_skb(skb, rxrpc_skb_see_unshare_nomem);
+			ret = -ENOMEM;
+		}
+	} else {
+		ret = conn->security->verify_response(conn, skb);
+	}
+
+	return ret;
+}
+
 /*
  * connection-level Rx packet processor
  */
@@ -270,7 +297,7 @@ static int rxrpc_process_event(struct rxrpc_connection *conn,
 		}
 		spin_unlock_irq(&conn->state_lock);
 
-		ret = conn->security->verify_response(conn, skb);
+		ret = rxrpc_verify_response(conn, skb);
 		if (ret < 0)
 			return ret;
 

[PATCH 6.6.y] rxrpc: Fix conn-level packet handling to unshare RESPONSE packets

[Sasha Levin]

From: David Howells <dhowells@redhat.com>

[ Upstream commit 24481a7f573305706054c59e275371f8d0fe919f ]

The security operations that verify the RESPONSE packets decrypt bits of it
in place - however, the sk_buff may be shared with a packet sniffer, which
would lead to the sniffer seeing an apparently corrupt packet (actually
decrypted).

Fix this by handing a copy of the packet off to the specific security
handler if the packet was cloned.

Fixes: 17926a79320a ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both")
Closes: https://sashiko.dev/#/patchset/20260408121252.2249051-1-dhowells%40redhat.com
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Marc Dionne <marc.dionne@auristor.com>
cc: Jeffrey Altman <jaltman@auristor.com>
cc: Simon Horman <horms@kernel.org>
cc: linux-afs@lists.infradead.org
cc: stable@kernel.org
Link: https://patch.msgid.link/20260422161438.2593376-5-dhowells@redhat.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 include/trace/events/rxrpc.h |  2 ++
 net/rxrpc/conn_event.c       | 29 ++++++++++++++++++++++++++++-
 2 files changed, 30 insertions(+), 1 deletion(-)

diff --git a/include/trace/events/rxrpc.h b/include/trace/events/rxrpc.h
index 6965099dda89f..e8a5beca79cff 100644
--- a/include/trace/events/rxrpc.h
+++ b/include/trace/events/rxrpc.h
@@ -145,12 +145,14 @@
 	EM(rxrpc_skb_put_jumbo_subpacket,	"PUT jumbo-sub") \
 	EM(rxrpc_skb_put_last_nack,		"PUT last-nack") \
 	EM(rxrpc_skb_put_purge,			"PUT purge    ") \
+	EM(rxrpc_skb_put_response_copy,		"PUT resp-cpy ") \
 	EM(rxrpc_skb_put_rotate,		"PUT rotate   ") \
 	EM(rxrpc_skb_put_unknown,		"PUT unknown  ") \
 	EM(rxrpc_skb_see_conn_work,		"SEE conn-work") \
 	EM(rxrpc_skb_see_recvmsg,		"SEE recvmsg  ") \
 	EM(rxrpc_skb_see_reject,		"SEE reject   ") \
 	EM(rxrpc_skb_see_rotate,		"SEE rotate   ") \
+	EM(rxrpc_skb_see_unshare_nomem,		"SEE unshar-nm") \
 	E_(rxrpc_skb_see_version,		"SEE version  ")
 
 #define rxrpc_local_traces \
diff --git a/net/rxrpc/conn_event.c b/net/rxrpc/conn_event.c
index 6ef2dc1aa8cc2..6d7b064661d88 100644
--- a/net/rxrpc/conn_event.c
+++ b/net/rxrpc/conn_event.c
@@ -226,6 +226,33 @@ static void rxrpc_call_is_secure(struct rxrpc_call *call)
 		rxrpc_notify_socket(call);
 }
 
+static int rxrpc_verify_response(struct rxrpc_connection *conn,
+				 struct sk_buff *skb)
+{
+	int ret;
+
+	if (skb_cloned(skb)) {
+		/* Copy the packet if shared so that we can do in-place
+		 * decryption.
+		 */
+		struct sk_buff *nskb = skb_copy(skb, GFP_NOFS);
+
+		if (nskb) {
+			rxrpc_new_skb(nskb, rxrpc_skb_new_unshared);
+			ret = conn->security->verify_response(conn, nskb);
+			rxrpc_free_skb(nskb, rxrpc_skb_put_response_copy);
+		} else {
+			/* OOM - Drop the packet. */
+			rxrpc_see_skb(skb, rxrpc_skb_see_unshare_nomem);
+			ret = -ENOMEM;
+		}
+	} else {
+		ret = conn->security->verify_response(conn, skb);
+	}
+
+	return ret;
+}
+
 /*
  * connection-level Rx packet processor
  */
@@ -253,7 +280,7 @@ static int rxrpc_process_event(struct rxrpc_connection *conn,
 		}
 		spin_unlock(&conn->state_lock);
 
-		ret = conn->security->verify_response(conn, skb);
+		ret = rxrpc_verify_response(conn, skb);
 		if (ret < 0)
 			return ret;
 
-- 
2.53.0

[PATCH RFC 6.6] rxrpc: Fix potential UAF after skb_unshare() failure

[Wentao Guan]

From: David Howells <dhowells@redhat.com>

[ Upstream commit 1f2740150f904bfa60e4bad74d65add3ccb5e7f8 ]

If skb_unshare() fails to unshare a packet due to allocation failure in
rxrpc_input_packet(), the skb pointer in the parent (rxrpc_io_thread())
will be NULL'd out.  This will likely cause the call to
trace_rxrpc_rx_done() to oops.

Fix this by moving the unsharing down to where rxrpc_input_call_event()
calls rxrpc_input_call_packet().  There are a number of places prior to
that where we ignore DATA packets for a variety of reasons (such as the
call already being complete) for which an unshare is then avoided.

And with that, rxrpc_input_packet() doesn't need to take a pointer to the
pointer to the packet, so change that to just a pointer.

Fixes: 2d1faf7a0ca3 ("rxrpc: Simplify skbuff accounting in receive path")
Closes: https://sashiko.dev/#/patchset/20260408121252.2249051-1-dhowells%40redhat.com
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Marc Dionne <marc.dionne@auristor.com>
cc: Jeffrey Altman <jaltman@auristor.com>
cc: Simon Horman <horms@kernel.org>
cc: linux-afs@lists.infradead.org
cc: stable@kernel.org
Link: https://patch.msgid.link/20260422161438.2593376-4-dhowells@redhat.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
[ Relocated the unshare/skb_copy block from rxrpc_input_call_event()'s rx_queue dequeue loop to existing `if (skb) rxrpc_input_call_packet()` site, and substituted rxrpc_skb_put_call_rx with rxrpc_skb_put_input. ]
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Readd rxrpc_skb_put_response_copy() or will cause a build fail with commit 24481a7f5733 ("rxrpc: Fix conn-level packet handling to unshare RESPONSE packets") ]
Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
---
changelog:
add rxrpc_skb_put_response_copy to include/trace/events/rxrpc.h
to fix the build err if bring the upstream commit
24481a7f5733 ("rxrpc: Fix conn-level packet handling to unshare RESPONSE packets")

---
---
 include/trace/events/rxrpc.h |  4 ++--
 net/rxrpc/ar-internal.h      |  1 -
 net/rxrpc/call_event.c       | 23 +++++++++++++++++++++--
 net/rxrpc/io_thread.c        | 24 ++----------------------
 net/rxrpc/skbuff.c           |  9 ---------
 5 files changed, 25 insertions(+), 36 deletions(-)

diff --git a/include/trace/events/rxrpc.h b/include/trace/events/rxrpc.h
index 539801f8ee282..f0560087637ed 100644
--- a/include/trace/events/rxrpc.h
+++ b/include/trace/events/rxrpc.h
@@ -126,8 +126,6 @@
 	E_(rxrpc_call_poke_timer_now,		"Timer-now")
 
 #define rxrpc_skb_traces \
-	EM(rxrpc_skb_eaten_by_unshare,		"ETN unshare  ") \
-	EM(rxrpc_skb_eaten_by_unshare_nomem,	"ETN unshar-nm") \
 	EM(rxrpc_skb_get_conn_secured,		"GET conn-secd") \
 	EM(rxrpc_skb_get_conn_work,		"GET conn-work") \
 	EM(rxrpc_skb_get_last_nack,		"GET last-nack") \
@@ -146,12 +144,14 @@
 	EM(rxrpc_skb_put_jumbo_subpacket,	"PUT jumbo-sub") \
 	EM(rxrpc_skb_put_last_nack,		"PUT last-nack") \
 	EM(rxrpc_skb_put_purge,			"PUT purge    ") \
+	EM(rxrpc_skb_put_response_copy,		"PUT resp-cpy ") \
 	EM(rxrpc_skb_put_rotate,		"PUT rotate   ") \
 	EM(rxrpc_skb_put_unknown,		"PUT unknown  ") \
 	EM(rxrpc_skb_see_conn_work,		"SEE conn-work") \
 	EM(rxrpc_skb_see_recvmsg,		"SEE recvmsg  ") \
 	EM(rxrpc_skb_see_reject,		"SEE reject   ") \
 	EM(rxrpc_skb_see_rotate,		"SEE rotate   ") \
+	EM(rxrpc_skb_see_unshare_nomem,		"SEE unshar-nm") \
 	E_(rxrpc_skb_see_version,		"SEE version  ")
 
 #define rxrpc_local_traces \
diff --git a/net/rxrpc/ar-internal.h b/net/rxrpc/ar-internal.h
index f4512761f572d..1db479f3d6d3c 100644
--- a/net/rxrpc/ar-internal.h
+++ b/net/rxrpc/ar-internal.h
@@ -1269,7 +1269,6 @@ int rxrpc_server_keyring(struct rxrpc_sock *, sockptr_t, int);
 void rxrpc_kernel_data_consumed(struct rxrpc_call *, struct sk_buff *);
 void rxrpc_new_skb(struct sk_buff *, enum rxrpc_skb_trace);
 void rxrpc_see_skb(struct sk_buff *, enum rxrpc_skb_trace);
-void rxrpc_eaten_skb(struct sk_buff *, enum rxrpc_skb_trace);
 void rxrpc_get_skb(struct sk_buff *, enum rxrpc_skb_trace);
 void rxrpc_free_skb(struct sk_buff *, enum rxrpc_skb_trace);
 void rxrpc_purge_queue(struct sk_buff_head *);
diff --git a/net/rxrpc/call_event.c b/net/rxrpc/call_event.c
index 0f78544d043be..c8a4a4c979eb6 100644
--- a/net/rxrpc/call_event.c
+++ b/net/rxrpc/call_event.c
@@ -456,8 +456,27 @@ bool rxrpc_input_call_event(struct rxrpc_call *call, struct sk_buff *skb)
 		resend = true;
 	}
 
-	if (skb)
-		rxrpc_input_call_packet(call, skb);
+	if (skb) {
+		struct rxrpc_skb_priv *sp = rxrpc_skb(skb);
+
+		if (sp->hdr.securityIndex != 0 && skb_cloned(skb)) {
+			/* Unshare the packet so that it can be modified by
+			 * in-place decryption.
+			 */
+			struct sk_buff *nskb = skb_copy(skb, GFP_ATOMIC);
+
+			if (nskb) {
+				rxrpc_new_skb(nskb, rxrpc_skb_new_unshared);
+				rxrpc_input_call_packet(call, nskb);
+				rxrpc_free_skb(nskb, rxrpc_skb_put_input);
+			} else {
+				/* OOM - Drop the packet. */
+				rxrpc_see_skb(skb, rxrpc_skb_see_unshare_nomem);
+			}
+		} else {
+			rxrpc_input_call_packet(call, skb);
+		}
+	}
 
 	rxrpc_transmit_some_data(call);
 
diff --git a/net/rxrpc/io_thread.c b/net/rxrpc/io_thread.c
index 0491f2bbf61e0..f542eda13ff0b 100644
--- a/net/rxrpc/io_thread.c
+++ b/net/rxrpc/io_thread.c
@@ -167,13 +167,12 @@ static bool rxrpc_extract_abort(struct sk_buff *skb)
 /*
  * Process packets received on the local endpoint
  */
-static bool rxrpc_input_packet(struct rxrpc_local *local, struct sk_buff **_skb)
+static bool rxrpc_input_packet(struct rxrpc_local *local, struct sk_buff *skb)
 {
 	struct rxrpc_connection *conn;
 	struct sockaddr_rxrpc peer_srx;
 	struct rxrpc_skb_priv *sp;
 	struct rxrpc_peer *peer = NULL;
-	struct sk_buff *skb = *_skb;
 	bool ret = false;
 
 	skb_pull(skb, sizeof(struct udphdr));
@@ -219,25 +218,6 @@ static bool rxrpc_input_packet(struct rxrpc_local *local, struct sk_buff **_skb)
 			return rxrpc_bad_message(skb, rxrpc_badmsg_zero_call);
 		if (sp->hdr.seq == 0)
 			return rxrpc_bad_message(skb, rxrpc_badmsg_zero_seq);
-
-		/* Unshare the packet so that it can be modified for in-place
-		 * decryption.
-		 */
-		if (sp->hdr.securityIndex != 0) {
-			skb = skb_unshare(skb, GFP_ATOMIC);
-			if (!skb) {
-				rxrpc_eaten_skb(*_skb, rxrpc_skb_eaten_by_unshare_nomem);
-				*_skb = NULL;
-				return just_discard;
-			}
-
-			if (skb != *_skb) {
-				rxrpc_eaten_skb(*_skb, rxrpc_skb_eaten_by_unshare);
-				*_skb = skb;
-				rxrpc_new_skb(skb, rxrpc_skb_new_unshared);
-				sp = rxrpc_skb(skb);
-			}
-		}
 		break;
 
 	case RXRPC_PACKET_TYPE_CHALLENGE:
@@ -479,7 +459,7 @@ int rxrpc_io_thread(void *data)
 			switch (skb->mark) {
 			case RXRPC_SKB_MARK_PACKET:
 				skb->priority = 0;
-				if (!rxrpc_input_packet(local, &skb))
+				if (!rxrpc_input_packet(local, skb))
 					rxrpc_reject_packet(local, skb);
 				trace_rxrpc_rx_done(skb->mark, skb->priority);
 				rxrpc_free_skb(skb, rxrpc_skb_put_input);
diff --git a/net/rxrpc/skbuff.c b/net/rxrpc/skbuff.c
index 3bcd6ee803960..e2169d1a14b5f 100644
--- a/net/rxrpc/skbuff.c
+++ b/net/rxrpc/skbuff.c
@@ -46,15 +46,6 @@ void rxrpc_get_skb(struct sk_buff *skb, enum rxrpc_skb_trace why)
 	skb_get(skb);
 }
 
-/*
- * Note the dropping of a ref on a socket buffer by the core.
- */
-void rxrpc_eaten_skb(struct sk_buff *skb, enum rxrpc_skb_trace why)
-{
-	int n = atomic_inc_return(&rxrpc_n_rx_skbs);
-	trace_rxrpc_skb(skb, 0, n, why);
-}
-
 /*
  * Note the destruction of a socket buffer.
  */
-- 
2.30.2

Re: [PATCH RFC 6.6] rxrpc: Fix potential UAF after skb_unshare() failure

[Greg KH]

On Fri, May 08, 2026 at 04:31:42PM +0800, Wentao Guan wrote:
> From: David Howells <dhowells@redhat.com>
> 
> [ Upstream commit 1f2740150f904bfa60e4bad74d65add3ccb5e7f8 ]
> 
> If skb_unshare() fails to unshare a packet due to allocation failure in
> rxrpc_input_packet(), the skb pointer in the parent (rxrpc_io_thread())
> will be NULL'd out.  This will likely cause the call to
> trace_rxrpc_rx_done() to oops.
> 
> Fix this by moving the unsharing down to where rxrpc_input_call_event()
> calls rxrpc_input_call_packet().  There are a number of places prior to
> that where we ignore DATA packets for a variety of reasons (such as the
> call already being complete) for which an unshare is then avoided.
> 
> And with that, rxrpc_input_packet() doesn't need to take a pointer to the
> pointer to the packet, so change that to just a pointer.
> 
> Fixes: 2d1faf7a0ca3 ("rxrpc: Simplify skbuff accounting in receive path")
> Closes: https://sashiko.dev/#/patchset/20260408121252.2249051-1-dhowells%40redhat.com
> Signed-off-by: David Howells <dhowells@redhat.com>
> cc: Marc Dionne <marc.dionne@auristor.com>
> cc: Jeffrey Altman <jaltman@auristor.com>
> cc: Simon Horman <horms@kernel.org>
> cc: linux-afs@lists.infradead.org
> cc: stable@kernel.org
> Link: https://patch.msgid.link/20260422161438.2593376-4-dhowells@redhat.com
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> [ Relocated the unshare/skb_copy block from rxrpc_input_call_event()'s rx_queue dequeue loop to existing `if (skb) rxrpc_input_call_packet()` site, and substituted rxrpc_skb_put_call_rx with rxrpc_skb_put_input. ]
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> [ Readd rxrpc_skb_put_response_copy() or will cause a build fail with commit 24481a7f5733 ("rxrpc: Fix conn-level packet handling to unshare RESPONSE packets") ]
> Signed-off-by: Wentao Guan <guanwentao@uniontech.com>

Why not backport the needed commits before this one instead?  That would
make the difference here much smaller.

thanks,

greg k-h

Re: Re: [PATCH RFC 6.6] rxrpc: Fix potential UAF after skb_unshare() failure

[Wentao Guan]

Hello, sashal change substituted rxrpc_skb_put_call_rx with rxrpc_skb_put_input
which introduced from commit 9e3cccd176b5e ("rxrpc: Fix CPU time starvation in
I/O thread"). It is hard to clean cherry-pick for 6.6, but possible for v6.12.y?
Maybe the solution is ask for the subsystem maintainer to decide...

BRs
Wentao Guan

Re: [PATCH RFC 6.6] rxrpc: Fix potential UAF after skb_unshare() failure

[Sasha Levin]

> Subject: [PATCH RFC 6.6] rxrpc: Fix potential UAF after skb_unshare() failure
>
> [ Upstream commit 1f2740150f904bfa60e4bad74d65add3ccb5e7f8 ]
>
> [ Readd rxrpc_skb_put_response_copy() or will cause a build fail with commit
>   24481a7f5733 ("rxrpc: Fix conn-level packet handling to unshare RESPONSE
>   packets") ]

Queued for 6.6, thanks.

I also took the mainline follow-up 55b2984c96c37 ("rxrpc: Fix
rxrpc_input_call_event() to only unshare DATA packets", a Fixes:
of 1f2740150f90) on top, so 6.6 ends up with the same pair that
6.12 already shipped (bf20f46d94f1d + 016725807ce3). Without it
the unconditional skb_copy() of every cloned ACK/ABORT/ACKALL
would re-introduce exactly the regression that follow-up commit
fixed.

--
Thanks,
Sasha

Backport RXRPC for 6.1.y from 6.2

[Wentao Guan]

Hello All,

FYI, I found the commit list from v6.1..v6.2 mainline, with the refactor RXRPC 
commit list, it will possible for v6.1.172 to clean apply for the becoming fix
patches for AF_RXRPC in higher kernel version, but it a bit large...

BRs
Wentao Guan

commit list:
(usage: git checkout v6.1.172; git cherry-pick $(cat thepatchlistfile))
(from git log --oneline v6.1..v6.2 | grep rxrpc )
4d843be56ba6a8c0e566afd58775742d9e721505
334dfbfc5a7187c99761df2392dd4cc49c453bea
589a0c1e0ac31ccba49b214762e444dc015ee1e2
b015424695f03a9fa5862d09c267ed458e256300
f2a676d10038e8f3913dc576397b9c9efb190afd
f7fa52421f76309c574f2575701660bc3ea3a705
42fb06b391ace2aec5cdb1ebb8ff668f0a34332f
b6c66c4324e7dd66a06a6a034204ae7d4e95c28c
ed472b0c8783e7e3896a8fb4382f2187aae427e1
23b237f3259299b75dd2ffefc7a4af889ba308c8
27f699ccb89d65165175525254fec3d9d6b8d500
a11e6ff961a01884482b2a70ced74a5c62d96801
02a1935640f8f8539b8f2dbd6eeb539de93b2ce4
72f0c6fb057971864fe4d42b289b8e6ede836ef1
530403d9ba1c3f51c721a394f642e56309072295
faf92e8d53f5f03842da25af971a3f0ef88ffba2
d4d02d8bb5c412d977af7ea7c7ea91977a6a64dc
5d7edbc9231ec6b60f9c5b7e7980e9a1cd92e6bb
a4ea4c47761943d90cd5d1688b3c3c65922ff2b1
4e76bd406d6e9208ea558953862a47524829688c
d57a3a151660902091491ac2633134e1be92557f
6869ddb87d475bde2da0dbd4d71270996d65cd47
1fc4fa2ac93dcf3542f2dc6f7ff88fb022da5116
30d95efe06e18bd55691902bb4ec873e4b21a754
41cf3a9156ba8e13e557e7908f9e22563b1f2828
6423ac2eb31ec33f8526dc48f1e541b665333970
66f6fd278c6780ea8c8bb7dac839132d8e76dd53
101c1bb6c55691d01c73915c118828f7ca17a049
38461894838bbbebab54cbd5a5459cc8d1b6dd9b
84924aac08a43169811b4814c67994a9154a6a82
75bfdbf2fca372e2709bcaa43e8cf1147766ae96
49df54a6b2953195243d037682cffb9038f9456a
30efa3ce109d9e852a1a7bb9be19a414e633b1f0
2ebdb26e6abd2a773ab5f009ac38a6de973a2bcf
e969c92ce597baf6aeff3f619d6c082d736575e0
2cc800863c49a1f4be1b10b756c09a878d3a3f00
f14febd8df5a490acc40b919808f163e997d7f03
0fde882fc9ee9cc2e66e8c5a5a93c83932d7ca95
47c810a79844462d3468d831edc00971757693e0
7fa25105b2d32fcb0f38668bc20d0adf6508322f
cb0fc0c9722c0c001510e2a6d9b0a78b80421487
fa3492abb64b93b2b5d6fdf7a5b687a1fa810d74
9a36a6bc22ca1c0a9d82228171e05dc785fa1154
3feda9d69c83983b530cea6287ba4fea0e5c3b87
3cec055c56958c5498eeb3ed9fb2aef2d28c030f
96b2d69b43a075a38df600597133f17d28525f24
a275da62e8c111b897b9cb73eb91df2f4e475ca5
446b3e14525b477e441a6bb8ce56cea12512acc2
ff7348254e704b6d0121970e311a6b699268e1ac
4041a8ff653ec4e4d9e6395802cb3f4fca59f7f3
81f2e8adc0fd10847637873dafe8610f3fb4cdff
15f661dc95daec9b38e8e4cc931c95afe0ae0cef
f3441d4125fc98995858550a5521b8d7daf0504a
cf37b5987508878647161ec3cdba0bb00a1b607a
29fb4ec385f18db98d9188c2173a0b07d2de6917
2d1faf7a0ca3c0b327cf064c80e4e775532c9319
cd21effb0552d666b2f8609560be764a1a56adbe
393a2a2007d13df7ae54c94328b45b6c2269b6a9
5e6ef4f1017c7f844e305283bbd8875af475e2fc
3dd9c8b5f09fd24652729a3da5c5efa3ec2c4590
32cf8edb079a6a687a2b5dba39a813a0bbd0ddf9
5086d9a9dfec4866806da303115489b0606decb7
a2cf3264f331acfeb7e463ad7b7fe1ac647a829d
b0346843b1076b34a0278ff601f8f287535cb064
fdb99487b0189f0ef883e353ad7484c78a8bd425
eaa02390adb03b82f04babebf0cdd233793aecf5
8fbcc83334a7b5b42b6bc1fae2458bf25eb57768
608aecd16a31269485e2980898029dd01b03a73e
c838f1a73d77abadb0810eff0e150ac88fef3da5
743d1768a008c8eae56ead497c9ba8237b14ee81
11e1706bc84f60040578056f8cef3d0139b92dda
31d35a02ad5b803354fe0727686fcbace7a343fe
0e50d999903c009b6a9cd2277c82d6798d982e31
8a758d98dba380a7d32a98b0840ad707e3036233
5040011d073d3acdeb58af2b64f84e33bb03abd2
30df927b936b2ef21eb07dce9c141c7897609643
a343b174b4bdde851033996960bca5ad1394d04b
03fc55adf8761c546d72798264b019c9f672c578
f2cce89a074e6d2991dddc94f6b6ebe1576b8459
a00ce28b1778fa3576575b43bdb17f60ded38b66
57af281e5389b6fefedb3685f86847cbb0055f75
f06cb29189361353e9ed12df936c8e1d7f69b730
2953d3b8d8fd1188034c54862b74402b0b846695
1bab27af6b88b5c811f99de4812b5590f20d1cb7
0b9bb322f13d486d5b8630264ccbfb4794bb43a9
d41b3f5b96881809c73f86e3ca436c9426610b7a
2d689424b6184535890c251f937ccf815fde9cd2
93368b6bd58ac49d804fdc9ab041a6dc89ebf1cc
96b4059f43ce69e9c590f77d6ce3e99888d5cfe6
0d6bf319bc5aba4535bb46e1b607973688a2248a
9d35d880e0e4a3ab32d8c12f9e4d76198aadd42d
42f229c350f57a8e825f7591e17cbc5c87e50235
01644a1f98ff45a4044395ce2bbfd534747e0676

Re: Backport RXRPC for 6.1.y from 6.2

[Greg KH]

On Sun, May 10, 2026 at 04:01:57AM +0800, Wentao Guan wrote:
> Hello All,
> 
> FYI, I found the commit list from v6.1..v6.2 mainline, with the refactor RXRPC 
> commit list, it will possible for v6.1.172 to clean apply for the becoming fix
> patches for AF_RXRPC in higher kernel version, but it a bit large...

Why is this needed?  If you want this, please provide a working set of
patches properly submitted, along with the reasoning why you just don't
move to a newer kernel version.  And do you really use the AFS
filesystem in a 6.1.y kernel tree?  If so, why?

thanks,

greg k-h

Re: Re: Backport RXRPC for 6.1.y from 6.2

[Wentao Guan]

> Why is this needed?  If you want this, please provide a working set of
> patches properly submitted, along with the reasoning why you just don't
> move to a newer kernel version.  And do you really use the AFS
> filesystem in a 6.1.y kernel tree?  If so, why?

FYI, there are bugfixes such as ("rxrpc: Fix conn-level packet handling to unshare RESPONSE packets")
affect the 6.1.y kernel, and the final goal is clean apply fixes for CVE-2026-43500 such as
("rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present") in maillist.

> move to a newer kernel version.  And do you really use the AFS
> filesystem in a 6.1.y kernel tree?  If so, why?
NO, just affected by compiled kernel which enabled the config:(,
we are preparing fix such as disable AFS and AF_RXRPC or fix it...

BRs
Wentao Guan

Re: Re: Backport RXRPC for 6.1.y from 6.2

[Greg KH]

On Mon, May 11, 2026 at 12:36:36AM +0800, Wentao Guan wrote:
> > Why is this needed?  If you want this, please provide a working set of
> > patches properly submitted, along with the reasoning why you just don't
> > move to a newer kernel version.  And do you really use the AFS
> > filesystem in a 6.1.y kernel tree?  If so, why?
> 
> FYI, there are bugfixes such as ("rxrpc: Fix conn-level packet handling to unshare RESPONSE packets")
> affect the 6.1.y kernel, and the final goal is clean apply fixes for CVE-2026-43500 such as
> ("rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present") in maillist.

That was not stated here at all, so we had no context :(

If you need/want those bugfixes, great!  Provide a patch series of them
and we will be glad to review them.

> > move to a newer kernel version.  And do you really use the AFS
> > filesystem in a 6.1.y kernel tree?  If so, why?
> NO, just affected by compiled kernel which enabled the config:(,
> we are preparing fix such as disable AFS and AF_RXRPC or fix it...

Great, if you don't need this, disable it and then you don't need the
backports either :)

thanks,

greg k-h

Re: Backport RXRPC for 6.1.y from 6.2

[Jeffrey E Altman]

[-- Attachment #1: Type: text/plain, Size: 1137 bytes --]

On 5/10/2026 12:36 PM, Wentao Guan wrote:
>> Why is this needed?  If you want this, please provide a working set of
>> patches properly submitted, along with the reasoning why you just don't
>> move to a newer kernel version.  And do you really use the AFS
>> filesystem in a 6.1.y kernel tree?  If so, why?
> FYI, there are bugfixes such as ("rxrpc: Fix conn-level packet handling to unshare RESPONSE packets")
> affect the 6.1.y kernel, and the final goal is clean apply fixes for CVE-2026-43500 such as
> ("rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present") in maillist.
>
>> move to a newer kernel version.  And do you really use the AFS
>> filesystem in a 6.1.y kernel tree?  If so, why?
> NO, just affected by compiled kernel which enabled the config:(,
> we are preparing fix such as disable AFS and AF_RXRPC or fix it...
>
> BRs
> Wentao Guan

Wentao,

Are you associated with a Linux distribution which ships 6.1.y stable?

Or are you building the kernel for local use?

Greg,

I believe Debian Bookworm ships 6.1.y kernels with RXRPC compiled and 
packaged.

Jeffrey Altman


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4467 bytes --]

Re: Re: Backport RXRPC for 6.1.y from 6.2

[Wentao Guan]

> Are you associated with a Linux distribution which ships 6.1.y stable?
We shiped 6.1 kernel past, and we are preparing the fix for it.

BRs
Wentao Guan

Re: Backport RXRPC for 6.1.y from 6.2

[Jeffrey E Altman]

[-- Attachment #1: Type: text/plain, Size: 1265 bytes --]

On 5/10/2026 1:41 PM, Wentao Guan wrote:
>> Are you associated with a Linux distribution which ships 6.1.y stable?
> We shiped 6.1 kernel past, and we are preparing the fix for it.
>
> BRs
> Wentao Guan

Wentao,

Have you confirmed that 6.1.179 is vulnerable to the exploit? When 
processing
a DATA packet a new unshared skb is allocated for the incoming packet
whenever decryption is required.

         /* Unshare the packet so that it can be modified for in-place
          * decryption.
          */
         if (sp->hdr.securityIndex != 0) {
             struct sk_buff *nskb = skb_unshare(skb, GFP_ATOMIC);
             if (!nskb) {
                 rxrpc_eaten_skb(skb, rxrpc_skb_unshared_nomem);
                 goto out;
             }

             if (nskb != skb) {
                 rxrpc_eaten_skb(skb, rxrpc_skb_received);
                 skb = nskb;
                 rxrpc_new_skb(skb, rxrpc_skb_unshared);
                 sp = rxrpc_skb(skb);
             }
         }

I cannot easily check but it doesn't look like 6.1.179 is vulnerable to 
CVE-2026-43500.

Please check.

Thank you.

Jeffrey Altman



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4467 bytes --]

Re: Backport RXRPC for 6.1.y from 6.2

[Wentao Guan]

> I cannot easily check but it doesn't look like 6.1.179 is vulnerable to 
6.1.179-> seem 6.1.172
> CVE-2026-43500.
FYI, to reproduce it, just runing a POC with CONFIG_AF_RXRPC + CONFIG_RXKAD,
i am sure without CONFIG_RXKAD it is not affected in v6.1.172 with my test.
POC: https://github.com/V4bel/dirtyfrag/blob/master/exp.c
(run it with '--force-rxrpc' or remove CONFIG_INET_ESP)

> Please check.
I will recheck it, i do many tests these days so I am 100% sure now,
i will reply when i finish my tests with 6.1.172.

> Please check.
I am sure that some 5.10 or 6.1 version are vulnerable with our tests.

BRs
Wentao Guan

Re: Backport RXRPC for 6.1.y from 6.2

[Jeffrey E Altman]

[-- Attachment #1: Type: text/plain, Size: 1125 bytes --]

On 5/10/2026 2:26 PM, Wentao Guan wrote:
>> I cannot easily check but it doesn't look like 6.1.179 is vulnerable to
> 6.1.179-> seem 6.1.172
>> CVE-2026-43500.
> FYI, to reproduce it, just runing a POC with CONFIG_AF_RXRPC + CONFIG_RXKAD,
> i am sure without CONFIG_RXKAD it is not affected in v6.1.172 with my test.
> POC: https://github.com/V4bel/dirtyfrag/blob/master/exp.c
> (run it with '--force-rxrpc' or remove CONFIG_INET_ESP)

RXRPC and RXKAD would be required to reproduce.   The POC does not 
attempt to try
the RXRPC case if the ESP case succeeds.  So the ESP case must be 
patched first or
disabled.

>> Please check.
> I will recheck it, i do many tests these days so I am 100% sure now,
> i will reply when i finish my tests with 6.1.172.
>
>> Please check.
> I am sure that some 5.10 or 6.1 version are vulnerable with our tests.
>
> BRs
> Wentao Guan
Back porting many years of RXRPC feature changes to fix this 
vulnerability if present
feels like the wrong thing to do.   If the vulnerability is present, we 
can try to find a

branch specific fix.

Jeffrey Altman



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4467 bytes --]

Re: Backport RXRPC for 6.1.y from 6.2

[Wentao Guan]

> Back porting many years of RXRPC feature changes to fix this 
> vulnerability if present
> feels like the wrong thing to do.   If the vulnerability is present, we 
I confirmed v6.1.70 is vulnerable with the poc, v6.1.172 not ok, I am doing
some bisects to figure out which version vulnerable or just fix poc.
FYI,[PATCH net v3] rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present
... Fixes: d0d5c0cd1e71 ("rxrpc: Use skb_unshare() rather than skb_cow_data()")
is in v5.3-rc7...:(, so it will affect 5.10.y 5.15.y 6.1.y than someone says >6.5 ver:(.
> can try to find a

> branch specific fix.
I am glad to see it:). 

BRs
Wentao Guan

Re: Backport RXRPC for 6.1.y from 6.2

[Jeffrey Altman]

[-- Attachment #1: Type: text/plain, Size: 1075 bytes --]


> On May 10, 2026, at 4:21 PM, Wentao Guan <guanwentao@uniontech.com> wrote:
> 
>> Back porting many years of RXRPC feature changes to fix this 
>> vulnerability if present
>> feels like the wrong thing to do.   If the vulnerability is present, we
> I confirmed v6.1.70 is vulnerable with the poc, v6.1.172 not ok, I am doing
> some bisects to figure out which version vulnerable or just fix poc.
> FYI,[PATCH net v3] rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present
> ... Fixes: d0d5c0cd1e71 ("rxrpc: Use skb_unshare() rather than skb_cow_data()")
> is in v5.3-rc7...:(, so it will affect 5.10.y 5.15.y 6.1.y than someone says >6.5 ver:(.
>> can try to find a
> 
>> branch specific fix.
> I am glad to see it:). 
> 
> BRs
> Wentao Guan

v6.1.171 contains 5d55c7336f8032d434adcc5fab987ccc93a44aec
("xfrm: esp: avoid in-place decrypt on shared skb frags”) which prevents the esp4/esp6 variant.

If the POC fails with v6.1.171 then the RXRPC path is not vulnerable.

Thank you for your continued testing.

Jeffrey Altman


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 4120 bytes --]

Re: Backport RXRPC for 6.1.y from 6.2

[Wentao Guan]

FYI, I am bisecting v6.1.73(poc fail) and v6.1.70(poc ok).
Also, I checked 5.15.206, it is strange but vulnerable...
I use --force-rxrpc and not compile CONFIG_INET_ESP to avoid gone to esp path.

BRs
Wentao Guan

Re: Backport RXRPC for 6.1.y from 6.2

[Wentao Guan]

FYI, I am bisecting v6.1.73(poc fail) and v6.1.70(poc ok):
ac8c69e448f7e43586e102395844a117b0595031 is the first bad commit
commit ac8c69e448f7e43586e102395844a117b0595031 (HEAD)
Author: David Howells <dhowells@redhat.com>
Date:   Mon May 22 13:11:22 2023 +0100

    udp: Convert udp_sendpage() to use MSG_SPLICE_PAGES

    [ Upstream commit 7ac7c987850c3ec617c778f7bd871804dc1c648d ]

    Convert udp_sendpage() to use sendmsg() with MSG_SPLICE_PAGES rather than
    directly splicing in the pages itself.

    This allows ->sendpage() to be replaced by something that can handle
    multiple multipage folios in a single transaction.

    Signed-off-by: David Howells <dhowells@redhat.com>
    cc: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
    cc: David Ahern <dsahern@kernel.org>
    cc: Jens Axboe <axboe@kernel.dk>
    cc: Matthew Wilcox <willy@infradead.org>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: a0002127cd74 ("udp: move udp->no_check6_tx to udp->udp_flags")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 net/ipv4/udp.c | 51 ++++++---------------------------------------------
 1 file changed, 6 insertions(+), 45 deletions(-)
so if the 6.1.y kernel convert to full MSG_SPLICE_PAGES will be vulnerable.

BRs
Wentao Guan