From: Greg Kroah-Hartman Date: Fri, 24 Apr 2026 08:34:35 +0000 (+0200) Subject: 6.1-stable patches X-Git-Url: http://git.ipfire.org/gitweb/?a=commitdiff_plain;h=0be59a2aac8a63e2a7881a5578b159f52228705f;p=thirdparty%2Fkernel%2Fstable-queue.git 6.1-stable patches added patches: arm64-mm-fix-va-range-sanity-check.patch rxrpc-fix-anonymous-key-handling.patch rxrpc-only-handle-response-during-service-challenge.patch --- diff --git a/queue-6.1/arm64-mm-fix-va-range-sanity-check.patch b/queue-6.1/arm64-mm-fix-va-range-sanity-check.patch new file mode 100644 index 0000000000..68a64daa2b --- /dev/null +++ b/queue-6.1/arm64-mm-fix-va-range-sanity-check.patch @@ -0,0 +1,102 @@ +From ab9b4008092c86dc12497af155a0901cc1156999 Mon Sep 17 00:00:00 2001 +From: Mark Rutland +Date: Thu, 15 Jun 2023 11:26:28 +0100 +Subject: arm64: mm: fix VA-range sanity check + +From: Mark Rutland + +commit ab9b4008092c86dc12497af155a0901cc1156999 upstream. + +Both create_mapping_noalloc() and update_mapping_prot() sanity-check +their 'virt' parameter, but the check itself doesn't make much sense. +The condition used today appears to be a historical accident. + +The sanity-check condition: + + if ((virt >= PAGE_END) && (virt < VMALLOC_START)) { + [ ... warning here ... ] + return; + } + +... can only be true for the KASAN shadow region or the module region, +and there's no reason to exclude these specifically for creating and +updateing mappings. + +When arm64 support was first upstreamed in commit: + + c1cc1552616d0f35 ("arm64: MMU initialisation") + +... the condition was: + + if (virt < VMALLOC_START) { + [ ... warning here ... ] + return; + } + +At the time, VMALLOC_START was the lowest kernel address, and this was +checking whether 'virt' would be translated via TTBR1. + +Subsequently in commit: + + 14c127c957c1c607 ("arm64: mm: Flip kernel VA space") + +... the condition was changed to: + + if ((virt >= VA_START) && (virt < VMALLOC_START)) { + [ ... warning here ... ] + return; + } + +This appear to have been a thinko. The commit moved the linear map to +the bottom of the kernel address space, with VMALLOC_START being at the +halfway point. The old condition would warn for changes to the linear +map below this, and at the time VA_START was the end of the linear map. + +Subsequently we cleaned up the naming of VA_START in commit: + + 77ad4ce69321abbe ("arm64: memory: rename VA_START to PAGE_END") + +... keeping the erroneous condition as: + + if ((virt >= PAGE_END) && (virt < VMALLOC_START)) { + [ ... warning here ... ] + return; + } + +Correct the condition to check against the start of the TTBR1 address +space, which is currently PAGE_OFFSET. This simplifies the logic, and +more clearly matches the "outside kernel range" message in the warning. + +Signed-off-by: Mark Rutland +Cc: Russell King +Cc: Steve Capper +Cc: Will Deacon +Reviewed-by: Russell King (Oracle) +Link: https://lore.kernel.org/r/20230615102628.1052103-1-mark.rutland@arm.com +Signed-off-by: Catalin Marinas +Signed-off-by: Alva Lan +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/mm/mmu.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/arch/arm64/mm/mmu.c ++++ b/arch/arm64/mm/mmu.c +@@ -451,7 +451,7 @@ static phys_addr_t pgd_pgtable_alloc(int + static void __init create_mapping_noalloc(phys_addr_t phys, unsigned long virt, + phys_addr_t size, pgprot_t prot) + { +- if ((virt >= PAGE_END) && (virt < VMALLOC_START)) { ++ if (virt < PAGE_OFFSET) { + pr_warn("BUG: not creating mapping for %pa at 0x%016lx - outside kernel range\n", + &phys, virt); + return; +@@ -478,7 +478,7 @@ void __init create_pgd_mapping(struct mm + static void update_mapping_prot(phys_addr_t phys, unsigned long virt, + phys_addr_t size, pgprot_t prot) + { +- if ((virt >= PAGE_END) && (virt < VMALLOC_START)) { ++ if (virt < PAGE_OFFSET) { + pr_warn("BUG: not updating mapping for %pa at 0x%016lx - outside kernel range\n", + &phys, virt); + return; diff --git a/queue-6.1/rxrpc-fix-anonymous-key-handling.patch b/queue-6.1/rxrpc-fix-anonymous-key-handling.patch new file mode 100644 index 0000000000..5f90e269d3 --- /dev/null +++ b/queue-6.1/rxrpc-fix-anonymous-key-handling.patch @@ -0,0 +1,54 @@ +From stable+bounces-237687-greg=kroah.com@vger.kernel.org Tue Apr 14 02:39:44 2026 +From: Sasha Levin +Date: Mon, 13 Apr 2026 20:29:44 -0400 +Subject: rxrpc: Fix anonymous key handling +To: stable@vger.kernel.org +Cc: David Howells , Marc Dionne , Jeffrey Altman , Simon Horman , linux-afs@lists.infradead.org, stable@kernel.org, Jakub Kicinski , Sasha Levin +Message-ID: <20260414002944.3802386-1-sashal@kernel.org> + +From: David Howells + +[ Upstream commit 6a59d84b4fc2f27f7b40e348506cc686712e260b ] + +In rxrpc_new_client_call_for_sendmsg(), a key with no payload is meant to +be substituted for a NULL key pointer, but the variable this is done with +is subsequently not used. + +Fix this by using "key" rather than "rx->key" when filling in the +connection parameters. + +Note that this only affects direct use of AF_RXRPC; the kAFS filesystem +doesn't use sendmsg() directly and so bypasses the issue. Further, +AF_RXRPC passes a NULL key in if no key is set, so using an anonymous key +in that manner works. Since this hasn't been noticed to this point, it +might be better just to remove the "key" variable and the code that sets it +- and, arguably, rxrpc_init_client_call_security() would be a better place +to handle it. + +Fixes: 19ffa01c9c45 ("rxrpc: Use structs to hold connection params and protocol info") +Closes: https://sashiko.dev/#/patchset/20260319150150.4189381-1-dhowells%40redhat.com +Signed-off-by: David Howells +cc: Marc Dionne +cc: Jeffrey Altman +cc: Simon Horman +cc: linux-afs@lists.infradead.org +cc: stable@kernel.org +Link: https://patch.msgid.link/20260408121252.2249051-4-dhowells@redhat.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +Signed-off-by: Greg Kroah-Hartman +--- + net/rxrpc/sendmsg.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/net/rxrpc/sendmsg.c ++++ b/net/rxrpc/sendmsg.c +@@ -624,7 +624,7 @@ rxrpc_new_client_call_for_sendmsg(struct + + memset(&cp, 0, sizeof(cp)); + cp.local = rx->local; +- cp.key = rx->key; ++ cp.key = key; + cp.security_level = rx->min_sec_level; + cp.exclusive = rx->exclusive | p->exclusive; + cp.upgrade = p->upgrade; diff --git a/queue-6.1/rxrpc-only-handle-response-during-service-challenge.patch b/queue-6.1/rxrpc-only-handle-response-during-service-challenge.patch new file mode 100644 index 0000000000..bb4b9bbfc2 --- /dev/null +++ b/queue-6.1/rxrpc-only-handle-response-during-service-challenge.patch @@ -0,0 +1,90 @@ +From stable+bounces-237830-greg=kroah.com@vger.kernel.org Tue Apr 14 13:48:19 2026 +From: Sasha Levin +Date: Tue, 14 Apr 2026 07:45:29 -0400 +Subject: rxrpc: only handle RESPONSE during service challenge +To: stable@vger.kernel.org +Cc: Wang Jie , Yifan Wu , Juefei Pu , Yuan Tan , Xin Liu , Yang Yang , David Howells , Marc Dionne , Jeffrey Altman , Simon Horman , linux-afs@lists.infradead.org, stable@kernel.org, Jakub Kicinski , Sasha Levin +Message-ID: <20260414114529.521040-1-sashal@kernel.org> + +From: Wang Jie + +[ Upstream commit c43ffdcfdbb5567b1f143556df8a04b4eeea041c ] + +Only process RESPONSE packets while the service connection is still in +RXRPC_CONN_SERVICE_CHALLENGING. Check that state under state_lock before +running response verification and security initialization, then use a local +secured flag to decide whether to queue the secured-connection work after +the state transition. This keeps duplicate or late RESPONSE packets from +re-running the setup path and removes the unlocked post-transition state +test. + +Fixes: 17926a79320a ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both") +Reported-by: Yifan Wu +Reported-by: Juefei Pu +Co-developed-by: Yuan Tan +Signed-off-by: Yuan Tan +Suggested-by: Xin Liu +Signed-off-by: Jie Wang +Signed-off-by: Yang Yang +Signed-off-by: David Howells +cc: Marc Dionne +cc: Jeffrey Altman +cc: Simon Horman +cc: linux-afs@lists.infradead.org +cc: stable@kernel.org +Link: https://patch.msgid.link/20260408121252.2249051-21-dhowells@redhat.com +Signed-off-by: Jakub Kicinski +[ adapted to spin_lock_bh usage, 3-arg verify_response(), and direct rxrpc_call_is_secure() ] +Signed-off-by: Sasha Levin +Signed-off-by: Greg Kroah-Hartman +--- + net/rxrpc/conn_event.c | 17 +++++++++++++---- + 1 file changed, 13 insertions(+), 4 deletions(-) + +--- a/net/rxrpc/conn_event.c ++++ b/net/rxrpc/conn_event.c +@@ -293,6 +293,7 @@ static int rxrpc_process_event(struct rx + u32 *_abort_code) + { + struct rxrpc_skb_priv *sp = rxrpc_skb(skb); ++ bool secured = false; + __be32 wtmp; + u32 abort_code; + int loop, ret; +@@ -337,6 +338,13 @@ static int rxrpc_process_event(struct rx + _abort_code); + + case RXRPC_PACKET_TYPE_RESPONSE: ++ spin_lock_bh(&conn->state_lock); ++ if (conn->state != RXRPC_CONN_SERVICE_CHALLENGING) { ++ spin_unlock_bh(&conn->state_lock); ++ return 0; ++ } ++ spin_unlock_bh(&conn->state_lock); ++ + ret = conn->security->verify_response(conn, skb, _abort_code); + if (ret < 0) + return ret; +@@ -348,17 +356,18 @@ static int rxrpc_process_event(struct rx + + spin_lock(&conn->bundle->channel_lock); + spin_lock_bh(&conn->state_lock); +- + if (conn->state == RXRPC_CONN_SERVICE_CHALLENGING) { + conn->state = RXRPC_CONN_SERVICE; +- spin_unlock_bh(&conn->state_lock); ++ secured = true; ++ } ++ spin_unlock_bh(&conn->state_lock); ++ ++ if (secured) { + for (loop = 0; loop < RXRPC_MAXCALLS; loop++) + rxrpc_call_is_secure( + rcu_dereference_protected( + conn->channels[loop].call, + lockdep_is_held(&conn->bundle->channel_lock))); +- } else { +- spin_unlock_bh(&conn->state_lock); + } + + spin_unlock(&conn->bundle->channel_lock); diff --git a/queue-6.1/series b/queue-6.1/series index 104065d7c3..d9191ca717 100644 --- a/queue-6.1/series +++ b/queue-6.1/series @@ -138,3 +138,6 @@ alsa-control-avoid-warn-for-symlink-errors.patch f2fs-fix-null-ptr-deref-in-f2fs_submit_page_bio.patch wifi-iwlwifi-read-txq-read_ptr-under-lock.patch scripts-dtc-remove-unused-dts_version-in-dtc-lexer.l.patch +arm64-mm-fix-va-range-sanity-check.patch +rxrpc-fix-anonymous-key-handling.patch +rxrpc-only-handle-response-during-service-challenge.patch