From: Greg Kroah-Hartman Date: Thu, 23 May 2024 12:09:31 +0000 (+0200) Subject: 5.10-stable patches X-Git-Tag: v4.19.315~11 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=6900c32262281a9812db12e2fc1b1b6f6fdbf7b3;p=thirdparty%2Fkernel%2Fstable-queue.git 5.10-stable patches added patches: btrfs-add-missing-mutex_unlock-in-btrfs_relocate_sys_chunks.patch drm-amdgpu-fix-possible-null-dereference-in-amdgpu_ras_query_error_status_helper.patch firmware-arm_scmi-harden-accesses-to-the-reset-domains.patch kvm-x86-clear-has_error_code-not-error_code-for-rm-exception-injection.patch mptcp-ensure-snd_nxt-is-properly-initialized-on-connect.patch netlink-annotate-lockless-accesses-to-nlk-max_recvmsg_len.patch --- diff --git a/queue-5.10/btrfs-add-missing-mutex_unlock-in-btrfs_relocate_sys_chunks.patch b/queue-5.10/btrfs-add-missing-mutex_unlock-in-btrfs_relocate_sys_chunks.patch new file mode 100644 index 00000000000..cf7c802d9a0 --- /dev/null +++ b/queue-5.10/btrfs-add-missing-mutex_unlock-in-btrfs_relocate_sys_chunks.patch @@ -0,0 +1,36 @@ +From 9af503d91298c3f2945e73703f0e00995be08c30 Mon Sep 17 00:00:00 2001 +From: Dominique Martinet +Date: Fri, 19 Apr 2024 11:22:48 +0900 +Subject: btrfs: add missing mutex_unlock in btrfs_relocate_sys_chunks() + +From: Dominique Martinet + +commit 9af503d91298c3f2945e73703f0e00995be08c30 upstream. + +The previous patch that replaced BUG_ON by error handling forgot to +unlock the mutex in the error path. + +Link: https://lore.kernel.org/all/Zh%2fHpAGFqa7YAFuM@duo.ucw.cz +Reported-by: Pavel Machek +Fixes: 7411055db5ce ("btrfs: handle chunk tree lookup error in btrfs_relocate_sys_chunks()") +CC: stable@vger.kernel.org +Reviewed-by: Pavel Machek +Signed-off-by: Dominique Martinet +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Dominique Martinet +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/volumes.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/fs/btrfs/volumes.c ++++ b/fs/btrfs/volumes.c +@@ -3194,6 +3194,7 @@ again: + * alignment and size). + */ + ret = -EUCLEAN; ++ mutex_unlock(&fs_info->delete_unused_bgs_mutex); + goto error; + } + diff --git a/queue-5.10/drm-amdgpu-fix-possible-null-dereference-in-amdgpu_ras_query_error_status_helper.patch b/queue-5.10/drm-amdgpu-fix-possible-null-dereference-in-amdgpu_ras_query_error_status_helper.patch new file mode 100644 index 00000000000..af2575ea318 --- /dev/null +++ b/queue-5.10/drm-amdgpu-fix-possible-null-dereference-in-amdgpu_ras_query_error_status_helper.patch @@ -0,0 +1,47 @@ +From b8d55a90fd55b767c25687747e2b24abd1ef8680 Mon Sep 17 00:00:00 2001 +From: Srinivasan Shanmugam +Date: Tue, 26 Dec 2023 15:32:19 +0530 +Subject: drm/amdgpu: Fix possible NULL dereference in amdgpu_ras_query_error_status_helper() +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Srinivasan Shanmugam + +commit b8d55a90fd55b767c25687747e2b24abd1ef8680 upstream. + +Return invalid error code -EINVAL for invalid block id. + +Fixes the below: + +drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:1183 amdgpu_ras_query_error_status_helper() error: we previously assumed 'info' could be null (see line 1176) + +Suggested-by: Hawking Zhang +Cc: Tao Zhou +Cc: Hawking Zhang +Cc: Christian König +Cc: Alex Deucher +Signed-off-by: Srinivasan Shanmugam +Reviewed-by: Hawking Zhang +Signed-off-by: Alex Deucher +[Ajay: applied AMDGPU_RAS_BLOCK_COUNT condition to amdgpu_ras_error_query() + as amdgpu_ras_query_error_status_helper() not present in v5.10, v5.4 + amdgpu_ras_query_error_status_helper() was introduced in 8cc0f5669eb6] +Signed-off-by: Ajay Kaher +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c ++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c +@@ -765,6 +765,9 @@ int amdgpu_ras_error_query(struct amdgpu + if (!obj) + return -EINVAL; + ++ if (!info || info->head.block == AMDGPU_RAS_BLOCK_COUNT) ++ return -EINVAL; ++ + switch (info->head.block) { + case AMDGPU_RAS_BLOCK__UMC: + if (adev->umc.funcs->query_ras_error_count) diff --git a/queue-5.10/firmware-arm_scmi-harden-accesses-to-the-reset-domains.patch b/queue-5.10/firmware-arm_scmi-harden-accesses-to-the-reset-domains.patch new file mode 100644 index 00000000000..f3414ed9d7c --- /dev/null +++ b/queue-5.10/firmware-arm_scmi-harden-accesses-to-the-reset-domains.patch @@ -0,0 +1,41 @@ +From e9076ffbcaed5da6c182b144ef9f6e24554af268 Mon Sep 17 00:00:00 2001 +From: Cristian Marussi +Date: Wed, 17 Aug 2022 18:27:29 +0100 +Subject: firmware: arm_scmi: Harden accesses to the reset domains + +From: Cristian Marussi + +commit e9076ffbcaed5da6c182b144ef9f6e24554af268 upstream. + +Accessing reset domains descriptors by the index upon the SCMI drivers +requests through the SCMI reset operations interface can potentially +lead to out-of-bound violations if the SCMI driver misbehave. + +Add an internal consistency check before any such domains descriptors +accesses. + +Link: https://lore.kernel.org/r/20220817172731.1185305-5-cristian.marussi@arm.com +Signed-off-by: Cristian Marussi +Signed-off-by: Sudeep Holla +Signed-off-by: Dominique Martinet +Signed-off-by: Greg Kroah-Hartman +--- + drivers/firmware/arm_scmi/reset.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +--- a/drivers/firmware/arm_scmi/reset.c ++++ b/drivers/firmware/arm_scmi/reset.c +@@ -149,8 +149,12 @@ static int scmi_domain_reset(const struc + struct scmi_xfer *t; + struct scmi_msg_reset_domain_reset *dom; + struct scmi_reset_info *pi = handle->reset_priv; +- struct reset_dom_info *rdom = pi->dom_info + domain; ++ struct reset_dom_info *rdom; + ++ if (domain >= pi->num_domains) ++ return -EINVAL; ++ ++ rdom = pi->dom_info + domain; + if (rdom->async_reset) + flags |= ASYNCHRONOUS_RESET; + diff --git a/queue-5.10/kvm-x86-clear-has_error_code-not-error_code-for-rm-exception-injection.patch b/queue-5.10/kvm-x86-clear-has_error_code-not-error_code-for-rm-exception-injection.patch new file mode 100644 index 00000000000..db0725356d8 --- /dev/null +++ b/queue-5.10/kvm-x86-clear-has_error_code-not-error_code-for-rm-exception-injection.patch @@ -0,0 +1,57 @@ +From 6c41468c7c12d74843bb414fc00307ea8a6318c3 Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Wed, 22 Mar 2023 07:32:59 -0700 +Subject: KVM: x86: Clear "has_error_code", not "error_code", for RM exception injection + +From: Sean Christopherson + +commit 6c41468c7c12d74843bb414fc00307ea8a6318c3 upstream. + +When injecting an exception into a vCPU in Real Mode, suppress the error +code by clearing the flag that tracks whether the error code is valid, not +by clearing the error code itself. The "typo" was introduced by recent +fix for SVM's funky Paged Real Mode. + +Opportunistically hoist the logic above the tracepoint so that the trace +is coherent with respect to what is actually injected (this was also the +behavior prior to the buggy commit). + +Fixes: b97f07458373 ("KVM: x86: determine if an exception has an error code only when injecting it.") +Cc: stable@vger.kernel.org +Cc: Maxim Levitsky +Signed-off-by: Sean Christopherson +Message-Id: <20230322143300.2209476-2-seanjc@google.com> +Signed-off-by: Paolo Bonzini +[nsaenz: backport to 5.10.y] +Signed-off-by: Nicolas Saenz Julienne +Signed-off-by: Greg Kroah-Hartman +Acked-by: Sean Christopherson +--- + arch/x86/kvm/x86.c | 11 +++++++++-- + 1 file changed, 9 insertions(+), 2 deletions(-) + +--- a/arch/x86/kvm/x86.c ++++ b/arch/x86/kvm/x86.c +@@ -8501,13 +8501,20 @@ static void update_cr8_intercept(struct + + static void kvm_inject_exception(struct kvm_vcpu *vcpu) + { ++ /* ++ * Suppress the error code if the vCPU is in Real Mode, as Real Mode ++ * exceptions don't report error codes. The presence of an error code ++ * is carried with the exception and only stripped when the exception ++ * is injected as intercepted #PF VM-Exits for AMD's Paged Real Mode do ++ * report an error code despite the CPU being in Real Mode. ++ */ ++ vcpu->arch.exception.has_error_code &= is_protmode(vcpu); ++ + trace_kvm_inj_exception(vcpu->arch.exception.nr, + vcpu->arch.exception.has_error_code, + vcpu->arch.exception.error_code, + vcpu->arch.exception.injected); + +- if (vcpu->arch.exception.error_code && !is_protmode(vcpu)) +- vcpu->arch.exception.error_code = false; + kvm_x86_ops.queue_exception(vcpu); + } + diff --git a/queue-5.10/mptcp-ensure-snd_nxt-is-properly-initialized-on-connect.patch b/queue-5.10/mptcp-ensure-snd_nxt-is-properly-initialized-on-connect.patch new file mode 100644 index 00000000000..58489dba2f9 --- /dev/null +++ b/queue-5.10/mptcp-ensure-snd_nxt-is-properly-initialized-on-connect.patch @@ -0,0 +1,86 @@ +From fb7a0d334894206ae35f023a82cad5a290fd7386 Mon Sep 17 00:00:00 2001 +From: Paolo Abeni +Date: Mon, 29 Apr 2024 20:00:31 +0200 +Subject: mptcp: ensure snd_nxt is properly initialized on connect + +From: Paolo Abeni + +commit fb7a0d334894206ae35f023a82cad5a290fd7386 upstream. + +Christoph reported a splat hinting at a corrupted snd_una: + + WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 + Modules linked in: + CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 #59 + Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 + Workqueue: events mptcp_worker + RIP: 0010:__mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 + Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8 + 8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe + <0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9 + RSP: 0018:ffffc9000013fd48 EFLAGS: 00010293 + RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4 + RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001 + RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 + R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000 + R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000 + FS: 0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 + CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 + CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0 + Call Trace: + + __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline] + mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline] + __mptcp_retrans+0x7f/0x7e0 net/mptcp/protocol.c:2615 + mptcp_worker+0x434/0x740 net/mptcp/protocol.c:2767 + process_one_work+0x1e0/0x560 kernel/workqueue.c:3254 + process_scheduled_works kernel/workqueue.c:3335 [inline] + worker_thread+0x3c7/0x640 kernel/workqueue.c:3416 + kthread+0x121/0x170 kernel/kthread.c:388 + ret_from_fork+0x44/0x50 arch/x86/kernel/process.c:147 + ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243 + + +When fallback to TCP happens early on a client socket, snd_nxt +is not yet initialized and any incoming ack will copy such value +into snd_una. If the mptcp worker (dumbly) tries mptcp-level +re-injection after such ack, that would unconditionally trigger a send +buffer cleanup using 'bad' snd_una values. + +We could easily disable re-injection for fallback sockets, but such +dumb behavior already helped catching a few subtle issues and a very +low to zero impact in practice. + +Instead address the issue always initializing snd_nxt (and write_seq, +for consistency) at connect time. + +Fixes: 8fd738049ac3 ("mptcp: fallback in case of simultaneous connect") +Cc: stable@vger.kernel.org +Reported-by: Christoph Paasch +Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/485 +Tested-by: Christoph Paasch +Signed-off-by: Paolo Abeni +Reviewed-by: Mat Martineau +Signed-off-by: Matthieu Baerts (NGI0) +Link: https://lore.kernel.org/r/20240429-upstream-net-20240429-mptcp-snd_nxt-init-connect-v1-1-59ceac0a7dcb@kernel.org +Signed-off-by: Jakub Kicinski +[ snd_nxt field is not available in v5.10.y: before, only write_seq was + used, see commit eaa2ffabfc35 ("mptcp: introduce MPTCP snd_nxt") for + more details about that. ] +Signed-off-by: Matthieu Baerts (NGI0) +Signed-off-by: Greg Kroah-Hartman +--- + net/mptcp/protocol.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/net/mptcp/protocol.c ++++ b/net/mptcp/protocol.c +@@ -2645,6 +2645,8 @@ static int mptcp_stream_connect(struct s + if (subflow->request_mptcp && mptcp_token_new_connect(ssock->sk)) + mptcp_subflow_early_fallback(msk, subflow); + ++ WRITE_ONCE(msk->write_seq, subflow->idsn); ++ + do_connect: + err = ssock->ops->connect(ssock, uaddr, addr_len, flags); + sock->state = ssock->state; diff --git a/queue-5.10/netlink-annotate-lockless-accesses-to-nlk-max_recvmsg_len.patch b/queue-5.10/netlink-annotate-lockless-accesses-to-nlk-max_recvmsg_len.patch new file mode 100644 index 00000000000..1e6d042f7df --- /dev/null +++ b/queue-5.10/netlink-annotate-lockless-accesses-to-nlk-max_recvmsg_len.patch @@ -0,0 +1,107 @@ +From a1865f2e7d10dde00d35a2122b38d2e469ae67ed Mon Sep 17 00:00:00 2001 +From: Eric Dumazet +Date: Mon, 3 Apr 2023 21:46:43 +0000 +Subject: netlink: annotate lockless accesses to nlk->max_recvmsg_len + +From: Eric Dumazet + +commit a1865f2e7d10dde00d35a2122b38d2e469ae67ed upstream. + +syzbot reported a data-race in data-race in netlink_recvmsg() [1] + +Indeed, netlink_recvmsg() can be run concurrently, +and netlink_dump() also needs protection. + +[1] +BUG: KCSAN: data-race in netlink_recvmsg / netlink_recvmsg + +read to 0xffff888141840b38 of 8 bytes by task 23057 on cpu 0: +netlink_recvmsg+0xea/0x730 net/netlink/af_netlink.c:1988 +sock_recvmsg_nosec net/socket.c:1017 [inline] +sock_recvmsg net/socket.c:1038 [inline] +__sys_recvfrom+0x1ee/0x2e0 net/socket.c:2194 +__do_sys_recvfrom net/socket.c:2212 [inline] +__se_sys_recvfrom net/socket.c:2208 [inline] +__x64_sys_recvfrom+0x78/0x90 net/socket.c:2208 +do_syscall_x64 arch/x86/entry/common.c:50 [inline] +do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 +entry_SYSCALL_64_after_hwframe+0x63/0xcd + +write to 0xffff888141840b38 of 8 bytes by task 23037 on cpu 1: +netlink_recvmsg+0x114/0x730 net/netlink/af_netlink.c:1989 +sock_recvmsg_nosec net/socket.c:1017 [inline] +sock_recvmsg net/socket.c:1038 [inline] +____sys_recvmsg+0x156/0x310 net/socket.c:2720 +___sys_recvmsg net/socket.c:2762 [inline] +do_recvmmsg+0x2e5/0x710 net/socket.c:2856 +__sys_recvmmsg net/socket.c:2935 [inline] +__do_sys_recvmmsg net/socket.c:2958 [inline] +__se_sys_recvmmsg net/socket.c:2951 [inline] +__x64_sys_recvmmsg+0xe2/0x160 net/socket.c:2951 +do_syscall_x64 arch/x86/entry/common.c:50 [inline] +do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 +entry_SYSCALL_64_after_hwframe+0x63/0xcd + +value changed: 0x0000000000000000 -> 0x0000000000001000 + +Reported by Kernel Concurrency Sanitizer on: +CPU: 1 PID: 23037 Comm: syz-executor.2 Not tainted 6.3.0-rc4-syzkaller-00195-g5a57b48fdfcb #0 +Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023 + +Fixes: 9063e21fb026 ("netlink: autosize skb lengthes") +Reported-by: syzbot +Signed-off-by: Eric Dumazet +Reviewed-by: Simon Horman +Link: https://lore.kernel.org/r/20230403214643.768555-1-edumazet@google.com +Signed-off-by: Jakub Kicinski +Signed-off-by: yenchia.chen +Signed-off-by: Greg Kroah-Hartman +--- + net/netlink/af_netlink.c | 15 +++++++++------ + 1 file changed, 9 insertions(+), 6 deletions(-) + +--- a/net/netlink/af_netlink.c ++++ b/net/netlink/af_netlink.c +@@ -1927,7 +1927,7 @@ static int netlink_recvmsg(struct socket + struct sock *sk = sock->sk; + struct netlink_sock *nlk = nlk_sk(sk); + int noblock = flags & MSG_DONTWAIT; +- size_t copied; ++ size_t copied, max_recvmsg_len; + struct sk_buff *skb, *data_skb; + int err, ret; + +@@ -1960,9 +1960,10 @@ static int netlink_recvmsg(struct socket + #endif + + /* Record the max length of recvmsg() calls for future allocations */ +- nlk->max_recvmsg_len = max(nlk->max_recvmsg_len, len); +- nlk->max_recvmsg_len = min_t(size_t, nlk->max_recvmsg_len, +- SKB_WITH_OVERHEAD(32768)); ++ max_recvmsg_len = max(READ_ONCE(nlk->max_recvmsg_len), len); ++ max_recvmsg_len = min_t(size_t, max_recvmsg_len, ++ SKB_WITH_OVERHEAD(32768)); ++ WRITE_ONCE(nlk->max_recvmsg_len, max_recvmsg_len); + + copied = data_skb->len; + if (len < copied) { +@@ -2211,6 +2212,7 @@ static int netlink_dump(struct sock *sk) + struct netlink_ext_ack extack = {}; + struct netlink_callback *cb; + struct sk_buff *skb = NULL; ++ size_t max_recvmsg_len; + struct module *module; + int err = -ENOBUFS; + int alloc_min_size; +@@ -2233,8 +2235,9 @@ static int netlink_dump(struct sock *sk) + cb = &nlk->cb; + alloc_min_size = max_t(int, cb->min_dump_alloc, NLMSG_GOODSIZE); + +- if (alloc_min_size < nlk->max_recvmsg_len) { +- alloc_size = nlk->max_recvmsg_len; ++ max_recvmsg_len = READ_ONCE(nlk->max_recvmsg_len); ++ if (alloc_min_size < max_recvmsg_len) { ++ alloc_size = max_recvmsg_len; + skb = alloc_skb(alloc_size, + (GFP_KERNEL & ~__GFP_DIRECT_RECLAIM) | + __GFP_NOWARN | __GFP_NORETRY); diff --git a/queue-5.10/series b/queue-5.10/series index 9f56926b9e3..b8f0c432339 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -4,3 +4,9 @@ revert-selftests-mm-fix-map_hugetlb-failure-on-64k-page-size-systems.patch net-bcmgenet-synchronize-ext_rgmii_oob_ctrl-access.patch net-bcmgenet-synchronize-umac_cmd-access.patch ima-fix-deadlock-when-traversing-ima_default_rules.patch +netlink-annotate-lockless-accesses-to-nlk-max_recvmsg_len.patch +kvm-x86-clear-has_error_code-not-error_code-for-rm-exception-injection.patch +firmware-arm_scmi-harden-accesses-to-the-reset-domains.patch +mptcp-ensure-snd_nxt-is-properly-initialized-on-connect.patch +btrfs-add-missing-mutex_unlock-in-btrfs_relocate_sys_chunks.patch +drm-amdgpu-fix-possible-null-dereference-in-amdgpu_ras_query_error_status_helper.patch