--- /dev/null
+From ab9b4008092c86dc12497af155a0901cc1156999 Mon Sep 17 00:00:00 2001
+From: Mark Rutland <mark.rutland@arm.com>
+Date: Thu, 15 Jun 2023 11:26:28 +0100
+Subject: arm64: mm: fix VA-range sanity check
+
+From: Mark Rutland <mark.rutland@arm.com>
+
+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 <mark.rutland@arm.com>
+Cc: Russell King <linux@armlinux.org.uk>
+Cc: Steve Capper <steve.capper@arm.com>
+Cc: Will Deacon <will@kernel.org>
+Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
+Link: https://lore.kernel.org/r/20230615102628.1052103-1-mark.rutland@arm.com
+Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
+Signed-off-by: Alva Lan <alvalan9@foxmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From stable+bounces-237687-greg=kroah.com@vger.kernel.org Tue Apr 14 02:39:44 2026
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 13 Apr 2026 20:29:44 -0400
+Subject: rxrpc: Fix anonymous key handling
+To: stable@vger.kernel.org
+Cc: David Howells <dhowells@redhat.com>, Marc Dionne <marc.dionne@auristor.com>, Jeffrey Altman <jaltman@auristor.com>, Simon Horman <horms@kernel.org>, linux-afs@lists.infradead.org, stable@kernel.org, Jakub Kicinski <kuba@kernel.org>, Sasha Levin <sashal@kernel.org>
+Message-ID: <20260414002944.3802386-1-sashal@kernel.org>
+
+From: David Howells <dhowells@redhat.com>
+
+[ 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 <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/20260408121252.2249051-4-dhowells@redhat.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From stable+bounces-237830-greg=kroah.com@vger.kernel.org Tue Apr 14 13:48:19 2026
+From: Sasha Levin <sashal@kernel.org>
+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 <jiewang2024@lzu.edu.cn>, Yifan Wu <yifanwucs@gmail.com>, Juefei Pu <tomapufckgml@gmail.com>, Yuan Tan <yuantan098@gmail.com>, Xin Liu <bird@lzu.edu.cn>, Yang Yang <n05ec@lzu.edu.cn>, David Howells <dhowells@redhat.com>, Marc Dionne <marc.dionne@auristor.com>, Jeffrey Altman <jaltman@auristor.com>, Simon Horman <horms@kernel.org>, linux-afs@lists.infradead.org, stable@kernel.org, Jakub Kicinski <kuba@kernel.org>, Sasha Levin <sashal@kernel.org>
+Message-ID: <20260414114529.521040-1-sashal@kernel.org>
+
+From: Wang Jie <jiewang2024@lzu.edu.cn>
+
+[ 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 <yifanwucs@gmail.com>
+Reported-by: Juefei Pu <tomapufckgml@gmail.com>
+Co-developed-by: Yuan Tan <yuantan098@gmail.com>
+Signed-off-by: Yuan Tan <yuantan098@gmail.com>
+Suggested-by: Xin Liu <bird@lzu.edu.cn>
+Signed-off-by: Jie Wang <jiewang2024@lzu.edu.cn>
+Signed-off-by: Yang Yang <n05ec@lzu.edu.cn>
+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/20260408121252.2249051-21-dhowells@redhat.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+[ adapted to spin_lock_bh usage, 3-arg verify_response(), and direct rxrpc_call_is_secure() ]
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
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
projects / thirdparty / kernel / stable-queue.git / commitdiff
