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

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 <[email protected]>.

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 '<[email protected]>' --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 <[email protected]>
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.

index 9a41ec708aeb..aee977291d90 100644
@@ -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;
 

From: David Howells <[email protected]>

[ 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.

---
 include/trace/events/rxrpc.h |  2 ++
 net/rxrpc/conn_event.c       | 29 ++++++++++++++++++++++++++++-
 2 files changed, 30 insertions(+), 1 deletion(-)

index 6965099dda89f..e8a5beca79cff 100644
@@ -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 \

index 6ef2dc1aa8cc2..6d7b064661d88 100644
@@ -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

From: David Howells <[email protected]>

[ 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.

---
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(-)

index 539801f8ee282..f0560087637ed 100644
@@ -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 \

index f4512761f572d..1db479f3d6d3c 100644
@@ -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 *);

index 0f78544d043be..c8a4a4c979eb6 100644
@@ -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);
 

index 0491f2bbf61e0..f542eda13ff0b 100644
@@ -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);

index 3bcd6ee803960..e2169d1a14b5f 100644
@@ -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

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

thanks,

greg k-h

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

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

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

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

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.

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

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.

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

thanks,

greg k-h

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

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

6.1.179-> seem 6.1.172

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)

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.

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

BRs
Wentao Guan

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.

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

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:(.

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

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

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 <[email protected]>
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.

Stable-dep-of: a0002127cd74 ("udp: move udp->no_check6_tx to udp->udp_flags")

 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