diff options
6 files changed, 372 insertions, 0 deletions
diff --git a/queue-6.1/arm64-ptrace-fix-stack-out-of-bounds-read-in-regs_ge.patch b/queue-6.1/arm64-ptrace-fix-stack-out-of-bounds-read-in-regs_ge.patch new file mode 100644 index 0000000000..ef043247d2 --- /dev/null +++ b/queue-6.1/arm64-ptrace-fix-stack-out-of-bounds-read-in-regs_ge.patch @@ -0,0 +1,107 @@ +From 3965a5913eb6e9a6017d130104f4cb09d1027e6f Mon Sep 17 00:00:00 2001 +From: Sasha Levin <sashal@kernel.org> +Date: Wed, 4 Jun 2025 00:55:33 +0000 +Subject: arm64/ptrace: Fix stack-out-of-bounds read in + regs_get_kernel_stack_nth() + +From: Tengda Wu <wutengda@huaweicloud.com> + +[ Upstream commit 39dfc971e42d886e7df01371cd1bef505076d84c ] + +KASAN reports a stack-out-of-bounds read in regs_get_kernel_stack_nth(). + +Call Trace: +[ 97.283505] BUG: KASAN: stack-out-of-bounds in regs_get_kernel_stack_nth+0xa8/0xc8 +[ 97.284677] Read of size 8 at addr ffff800089277c10 by task 1.sh/2550 +[ 97.285732] +[ 97.286067] CPU: 7 PID: 2550 Comm: 1.sh Not tainted 6.6.0+ #11 +[ 97.287032] Hardware name: linux,dummy-virt (DT) +[ 97.287815] Call trace: +[ 97.288279] dump_backtrace+0xa0/0x128 +[ 97.288946] show_stack+0x20/0x38 +[ 97.289551] dump_stack_lvl+0x78/0xc8 +[ 97.290203] print_address_description.constprop.0+0x84/0x3c8 +[ 97.291159] print_report+0xb0/0x280 +[ 97.291792] kasan_report+0x84/0xd0 +[ 97.292421] __asan_load8+0x9c/0xc0 +[ 97.293042] regs_get_kernel_stack_nth+0xa8/0xc8 +[ 97.293835] process_fetch_insn+0x770/0xa30 +[ 97.294562] kprobe_trace_func+0x254/0x3b0 +[ 97.295271] kprobe_dispatcher+0x98/0xe0 +[ 97.295955] kprobe_breakpoint_handler+0x1b0/0x210 +[ 97.296774] call_break_hook+0xc4/0x100 +[ 97.297451] brk_handler+0x24/0x78 +[ 97.298073] do_debug_exception+0xac/0x178 +[ 97.298785] el1_dbg+0x70/0x90 +[ 97.299344] el1h_64_sync_handler+0xcc/0xe8 +[ 97.300066] el1h_64_sync+0x78/0x80 +[ 97.300699] kernel_clone+0x0/0x500 +[ 97.301331] __arm64_sys_clone+0x70/0x90 +[ 97.302084] invoke_syscall+0x68/0x198 +[ 97.302746] el0_svc_common.constprop.0+0x11c/0x150 +[ 97.303569] do_el0_svc+0x38/0x50 +[ 97.304164] el0_svc+0x44/0x1d8 +[ 97.304749] el0t_64_sync_handler+0x100/0x130 +[ 97.305500] el0t_64_sync+0x188/0x190 +[ 97.306151] +[ 97.306475] The buggy address belongs to stack of task 1.sh/2550 +[ 97.307461] and is located at offset 0 in frame: +[ 97.308257] __se_sys_clone+0x0/0x138 +[ 97.308910] +[ 97.309241] This frame has 1 object: +[ 97.309873] [48, 184) 'args' +[ 97.309876] +[ 97.310749] The buggy address belongs to the virtual mapping at +[ 97.310749] [ffff800089270000, ffff800089279000) created by: +[ 97.310749] dup_task_struct+0xc0/0x2e8 +[ 97.313347] +[ 97.313674] The buggy address belongs to the physical page: +[ 97.314604] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14f69a +[ 97.315885] flags: 0x15ffffe00000000(node=1|zone=2|lastcpupid=0xfffff) +[ 97.316957] raw: 015ffffe00000000 0000000000000000 dead000000000122 0000000000000000 +[ 97.318207] raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 +[ 97.319445] page dumped because: kasan: bad access detected +[ 97.320371] +[ 97.320694] Memory state around the buggy address: +[ 97.321511] ffff800089277b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +[ 97.322681] ffff800089277b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +[ 97.323846] >ffff800089277c00: 00 00 f1 f1 f1 f1 f1 f1 00 00 00 00 00 00 00 00 +[ 97.325023] ^ +[ 97.325683] ffff800089277c80: 00 00 00 00 00 00 00 00 00 f3 f3 f3 f3 f3 f3 f3 +[ 97.326856] ffff800089277d00: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + +This issue seems to be related to the behavior of some gcc compilers and +was also fixed on the s390 architecture before: + + commit d93a855c31b7 ("s390/ptrace: Avoid KASAN false positives in regs_get_kernel_stack_nth()") + +As described in that commit, regs_get_kernel_stack_nth() has confirmed that +`addr` is on the stack, so reading the value at `*addr` should be allowed. +Use READ_ONCE_NOCHECK() helper to silence the KASAN check for this case. + +Fixes: 0a8ea52c3eb1 ("arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature") +Signed-off-by: Tengda Wu <wutengda@huaweicloud.com> +Link: https://lore.kernel.org/r/20250604005533.1278992-1-wutengda@huaweicloud.com +[will: Use '*addr' as the argument to READ_ONCE_NOCHECK()] +Signed-off-by: Will Deacon <will@kernel.org> +Signed-off-by: Sasha Levin <sashal@kernel.org> +--- + arch/arm64/kernel/ptrace.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c +index 2f1f86d916129..3025d14c253de 100644 +--- a/arch/arm64/kernel/ptrace.c ++++ b/arch/arm64/kernel/ptrace.c +@@ -139,7 +139,7 @@ unsigned long regs_get_kernel_stack_nth(struct pt_regs *regs, unsigned int n) + + addr += n; + if (regs_within_kernel_stack(regs, (unsigned long)addr)) +- return *addr; ++ return READ_ONCE_NOCHECK(*addr); + else + return 0; + } +-- +2.39.5 + diff --git a/queue-6.1/perf-fix-sample-vs-do_exit.patch b/queue-6.1/perf-fix-sample-vs-do_exit.patch new file mode 100644 index 0000000000..388c38b689 --- /dev/null +++ b/queue-6.1/perf-fix-sample-vs-do_exit.patch @@ -0,0 +1,102 @@ +From 5c3e334595eca81093303fe014cad4b9c1e00e71 Mon Sep 17 00:00:00 2001 +From: Sasha Levin <sashal@kernel.org> +Date: Thu, 5 Jun 2025 12:31:45 +0200 +Subject: perf: Fix sample vs do_exit() + +From: Peter Zijlstra <peterz@infradead.org> + +[ Upstream commit 4f6fc782128355931527cefe3eb45338abd8ab39 ] + +Baisheng Gao reported an ARM64 crash, which Mark decoded as being a +synchronous external abort -- most likely due to trying to access +MMIO in bad ways. + +The crash further shows perf trying to do a user stack sample while in +exit_mmap()'s tlb_finish_mmu() -- i.e. while tearing down the address +space it is trying to access. + +It turns out that we stop perf after we tear down the userspace mm; a +receipie for disaster, since perf likes to access userspace for +various reasons. + +Flip this order by moving up where we stop perf in do_exit(). + +Additionally, harden PERF_SAMPLE_CALLCHAIN and PERF_SAMPLE_STACK_USER +to abort when the current task does not have an mm (exit_mm() makes +sure to set current->mm = NULL; before commencing with the actual +teardown). Such that CPU wide events don't trip on this same problem. + +Fixes: c5ebcedb566e ("perf: Add ability to attach user stack dump to sample") +Reported-by: Baisheng Gao <baisheng.gao@unisoc.com> +Suggested-by: Mark Rutland <mark.rutland@arm.com> +Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> +Link: https://lkml.kernel.org/r/20250605110815.GQ39944@noisy.programming.kicks-ass.net +Signed-off-by: Sasha Levin <sashal@kernel.org> +--- + kernel/events/core.c | 7 +++++++ + kernel/exit.c | 17 +++++++++-------- + 2 files changed, 16 insertions(+), 8 deletions(-) + +diff --git a/kernel/events/core.c b/kernel/events/core.c +index 25df8971a56ed..2761db0365ddc 100644 +--- a/kernel/events/core.c ++++ b/kernel/events/core.c +@@ -6800,6 +6800,10 @@ perf_sample_ustack_size(u16 stack_size, u16 header_size, + if (!regs) + return 0; + ++ /* No mm, no stack, no dump. */ ++ if (!current->mm) ++ return 0; ++ + /* + * Check if we fit in with the requested stack size into the: + * - TASK_SIZE +@@ -7485,6 +7489,9 @@ perf_callchain(struct perf_event *event, struct pt_regs *regs) + const u32 max_stack = event->attr.sample_max_stack; + struct perf_callchain_entry *callchain; + ++ if (!current->mm) ++ user = false; ++ + if (!kernel && !user) + return &__empty_callchain; + +diff --git a/kernel/exit.c b/kernel/exit.c +index 156283b3c1bf6..10af26a4ab010 100644 +--- a/kernel/exit.c ++++ b/kernel/exit.c +@@ -855,6 +855,15 @@ void __noreturn do_exit(long code) + tsk->exit_code = code; + taskstats_exit(tsk, group_dead); + ++ /* ++ * Since sampling can touch ->mm, make sure to stop everything before we ++ * tear it down. ++ * ++ * Also flushes inherited counters to the parent - before the parent ++ * gets woken up by child-exit notifications. ++ */ ++ perf_event_exit_task(tsk); ++ + exit_mm(); + + if (group_dead) +@@ -871,14 +880,6 @@ void __noreturn do_exit(long code) + exit_task_work(tsk); + exit_thread(tsk); + +- /* +- * Flush inherited counters to the parent - before the parent +- * gets woken up by child-exit notifications. +- * +- * because of cgroup mode, must be called before cgroup_exit() +- */ +- perf_event_exit_task(tsk); +- + sched_autogroup_exit_task(tsk); + cgroup_exit(tsk); + +-- +2.39.5 + diff --git a/queue-6.1/risc-v-kvm-don-t-treat-sbi-hfence-calls-as-nops.patch b/queue-6.1/risc-v-kvm-don-t-treat-sbi-hfence-calls-as-nops.patch new file mode 100644 index 0000000000..70e5e2b6d2 --- /dev/null +++ b/queue-6.1/risc-v-kvm-don-t-treat-sbi-hfence-calls-as-nops.patch @@ -0,0 +1,46 @@ +From 801132cd9c523f8d3b99da95162279cc797cd994 Mon Sep 17 00:00:00 2001 +From: Sasha Levin <sashal@kernel.org> +Date: Thu, 5 Jun 2025 11:44:47 +0530 +Subject: RISC-V: KVM: Don't treat SBI HFENCE calls as NOPs +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Anup Patel <apatel@ventanamicro.com> + +[ Upstream commit 2e7be162996640bbe3b6da694cc064c511b8a5d9 ] + +The SBI specification clearly states that SBI HFENCE calls should +return SBI_ERR_NOT_SUPPORTED when one of the target hart doesn’t +support hypervisor extension (aka nested virtualization in-case +of KVM RISC-V). + +Fixes: c7fa3c48de86 ("RISC-V: KVM: Treat SBI HFENCE calls as NOPs") +Reviewed-by: Atish Patra <atishp@rivosinc.com> +Signed-off-by: Anup Patel <apatel@ventanamicro.com> +Link: https://lore.kernel.org/r/20250605061458.196003-3-apatel@ventanamicro.com +Signed-off-by: Anup Patel <anup@brainfault.org> +Signed-off-by: Sasha Levin <sashal@kernel.org> +--- + arch/riscv/kvm/vcpu_sbi_replace.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/arch/riscv/kvm/vcpu_sbi_replace.c b/arch/riscv/kvm/vcpu_sbi_replace.c +index 304d29383e6c0..1b8b3fa5f74ab 100644 +--- a/arch/riscv/kvm/vcpu_sbi_replace.c ++++ b/arch/riscv/kvm/vcpu_sbi_replace.c +@@ -113,9 +113,9 @@ static int kvm_sbi_ext_rfence_handler(struct kvm_vcpu *vcpu, struct kvm_run *run + case SBI_EXT_RFENCE_REMOTE_HFENCE_VVMA_ASID: + /* + * Until nested virtualization is implemented, the +- * SBI HFENCE calls should be treated as NOPs ++ * SBI HFENCE calls should return not supported ++ * hence fallthrough. + */ +- break; + default: + ret = -EOPNOTSUPP; + } +-- +2.39.5 + diff --git a/queue-6.1/risc-v-kvm-fix-the-size-parameter-check-in-sbi-sfenc.patch b/queue-6.1/risc-v-kvm-fix-the-size-parameter-check-in-sbi-sfenc.patch new file mode 100644 index 0000000000..9d1c8c41d3 --- /dev/null +++ b/queue-6.1/risc-v-kvm-fix-the-size-parameter-check-in-sbi-sfenc.patch @@ -0,0 +1,51 @@ +From 860e503d6fa707fda870158b8495fb62248fb836 Mon Sep 17 00:00:00 2001 +From: Sasha Levin <sashal@kernel.org> +Date: Thu, 5 Jun 2025 11:44:46 +0530 +Subject: RISC-V: KVM: Fix the size parameter check in SBI SFENCE calls + +From: Anup Patel <apatel@ventanamicro.com> + +[ Upstream commit 6aba0cb5bba6141158d5449f2cf53187b7f755f9 ] + +As-per the SBI specification, an SBI remote fence operation applies +to the entire address space if either: +1) start_addr and size are both 0 +2) size is equal to 2^XLEN-1 + +>From the above, only #1 is checked by SBI SFENCE calls so fix the +size parameter check in SBI SFENCE calls to cover #2 as well. + +Fixes: 13acfec2dbcc ("RISC-V: KVM: Add remote HFENCE functions based on VCPU requests") +Reviewed-by: Atish Patra <atishp@rivosinc.com> +Signed-off-by: Anup Patel <apatel@ventanamicro.com> +Link: https://lore.kernel.org/r/20250605061458.196003-2-apatel@ventanamicro.com +Signed-off-by: Anup Patel <anup@brainfault.org> +Signed-off-by: Sasha Levin <sashal@kernel.org> +--- + arch/riscv/kvm/vcpu_sbi_replace.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/arch/riscv/kvm/vcpu_sbi_replace.c b/arch/riscv/kvm/vcpu_sbi_replace.c +index 4c034d8a606a1..304d29383e6c0 100644 +--- a/arch/riscv/kvm/vcpu_sbi_replace.c ++++ b/arch/riscv/kvm/vcpu_sbi_replace.c +@@ -91,14 +91,14 @@ static int kvm_sbi_ext_rfence_handler(struct kvm_vcpu *vcpu, struct kvm_run *run + kvm_riscv_fence_i(vcpu->kvm, hbase, hmask); + break; + case SBI_EXT_RFENCE_REMOTE_SFENCE_VMA: +- if (cp->a2 == 0 && cp->a3 == 0) ++ if ((cp->a2 == 0 && cp->a3 == 0) || cp->a3 == -1UL) + kvm_riscv_hfence_vvma_all(vcpu->kvm, hbase, hmask); + else + kvm_riscv_hfence_vvma_gva(vcpu->kvm, hbase, hmask, + cp->a2, cp->a3, PAGE_SHIFT); + break; + case SBI_EXT_RFENCE_REMOTE_SFENCE_VMA_ASID: +- if (cp->a2 == 0 && cp->a3 == 0) ++ if ((cp->a2 == 0 && cp->a3 == 0) || cp->a3 == -1UL) + kvm_riscv_hfence_vvma_asid_all(vcpu->kvm, + hbase, hmask, cp->a4); + else +-- +2.39.5 + diff --git a/queue-6.1/scsi-elx-efct-fix-memory-leak-in-efct_hw_parse_filte.patch b/queue-6.1/scsi-elx-efct-fix-memory-leak-in-efct_hw_parse_filte.patch new file mode 100644 index 0000000000..2d50d7de92 --- /dev/null +++ b/queue-6.1/scsi-elx-efct-fix-memory-leak-in-efct_hw_parse_filte.patch @@ -0,0 +1,61 @@ +From a4e12cea1992238962763cd6e066dfaf96396087 Mon Sep 17 00:00:00 2001 +From: Sasha Levin <sashal@kernel.org> +Date: Thu, 12 Jun 2025 21:35:18 +0500 +Subject: scsi: elx: efct: Fix memory leak in efct_hw_parse_filter() + +From: Vitaliy Shevtsov <v.shevtsov@mt-integration.ru> + +[ Upstream commit 2a8a5a5dd06eef580f9818567773fd75057cb875 ] + +strsep() modifies the address of the pointer passed to it so that it no +longer points to the original address. This means kfree() gets the wrong +pointer. + +Fix this by passing unmodified pointer returned from kstrdup() to +kfree(). + +Found by Linux Verification Center (linuxtesting.org) with Svace. + +Fixes: 4df84e846624 ("scsi: elx: efct: Driver initialization routines") +Signed-off-by: Vitaliy Shevtsov <v.shevtsov@mt-integration.ru> +Link: https://lore.kernel.org/r/20250612163616.24298-1-v.shevtsov@mt-integration.ru +Reviewed-by: Daniel Wagner <dwagner@suse.de> +Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> +Signed-off-by: Sasha Levin <sashal@kernel.org> +--- + drivers/scsi/elx/efct/efct_hw.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +diff --git a/drivers/scsi/elx/efct/efct_hw.c b/drivers/scsi/elx/efct/efct_hw.c +index 5a5525054d71c..5b079b8b7a082 100644 +--- a/drivers/scsi/elx/efct/efct_hw.c ++++ b/drivers/scsi/elx/efct/efct_hw.c +@@ -1120,7 +1120,7 @@ int + efct_hw_parse_filter(struct efct_hw *hw, void *value) + { + int rc = 0; +- char *p = NULL; ++ char *p = NULL, *pp = NULL; + char *token; + u32 idx = 0; + +@@ -1132,6 +1132,7 @@ efct_hw_parse_filter(struct efct_hw *hw, void *value) + efc_log_err(hw->os, "p is NULL\n"); + return -ENOMEM; + } ++ pp = p; + + idx = 0; + while ((token = strsep(&p, ",")) && *token) { +@@ -1144,7 +1145,7 @@ efct_hw_parse_filter(struct efct_hw *hw, void *value) + if (idx == ARRAY_SIZE(hw->config.filter_def)) + break; + } +- kfree(p); ++ kfree(pp); + + return rc; + } +-- +2.39.5 + diff --git a/queue-6.1/series b/queue-6.1/series index ebe289dad3..55c22134ce 100644 --- a/queue-6.1/series +++ b/queue-6.1/series @@ -501,3 +501,8 @@ revert-cpufreq-tegra186-share-policy-per-cluster.patch smb-client-fix-first-command-failure-during-re-negotiation.patch platform-loongarch-laptop-add-backlight-power-control-support.patch s390-pci-fix-__pcilg_mio_inuser-inline-assembly.patch +perf-fix-sample-vs-do_exit.patch +arm64-ptrace-fix-stack-out-of-bounds-read-in-regs_ge.patch +scsi-elx-efct-fix-memory-leak-in-efct_hw_parse_filte.patch +risc-v-kvm-fix-the-size-parameter-check-in-sbi-sfenc.patch +risc-v-kvm-don-t-treat-sbi-hfence-calls-as-nops.patch |