From: Greg Kroah-Hartman Date: Sat, 12 Mar 2022 11:16:03 +0000 (+0100) Subject: 4.9-stable patches X-Git-Tag: v4.9.307~35 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=286c2520f19980ecb877ac13d562cb7dc7b2a3be;p=thirdparty%2Fkernel%2Fstable-queue.git 4.9-stable patches added patches: kvm-arm64-reset-pmc_el0-to-avoid-a-panic-on-systems-with-no-pmu.patch staging-gdm724x-fix-use-after-free-in-gdm_lte_rx.patch --- diff --git a/queue-4.9/kvm-arm64-reset-pmc_el0-to-avoid-a-panic-on-systems-with-no-pmu.patch b/queue-4.9/kvm-arm64-reset-pmc_el0-to-avoid-a-panic-on-systems-with-no-pmu.patch new file mode 100644 index 00000000000..9f8d2aeeead --- /dev/null +++ b/queue-4.9/kvm-arm64-reset-pmc_el0-to-avoid-a-panic-on-systems-with-no-pmu.patch @@ -0,0 +1,67 @@ +From james.morse@arm.com Sat Mar 12 12:08:36 2022 +From: James Morse +Date: Tue, 8 Mar 2022 16:29:39 +0000 +Subject: KVM: arm64: Reset PMC_EL0 to avoid a panic() on systems with no PMU +To: stable@vger.kernel.org, kvmarm@lists.cs.columbia.edu +Cc: Marc Zyngier , Alexandru Elisei , james.morse@arm.com +Message-ID: <20220308162939.603335-1-james.morse@arm.com> + +From: James Morse + +The logic in commit 2a5f1b67ec57 "KVM: arm64: Don't access PMCR_EL0 when no +PMU is available" relies on an empty reset handler being benign. This was +not the case in earlier kernel versions, so the stable backport of this +patch is causing problems. + +KVMs behaviour in this area changed over time. In particular, prior to commit +03fdfb269009 ("KVM: arm64: Don't write junk to sysregs on reset"), an empty +reset handler will trigger a warning, as the guest registers have been +poisoned. +Prior to commit 20589c8cc47d ("arm/arm64: KVM: Don't panic on failure to +properly reset system registers"), this warning was a panic(). + +Instead of reverting the backport, make it write 0 to the sys_reg[] array. +This keeps the reset logic happy, and the dodgy value can't be seen by +the guest as it can't request the emulation. + +The original bug was accessing the PMCR_EL0 register on CPUs that don't +implement that feature. There is no known silicon that does this, but +v4.9's ACPI support is unable to find the PMU, so triggers this code: + +| Kernel panic - not syncing: Didn't reset vcpu_sys_reg(24) +| CPU: 1 PID: 3055 Comm: lkvm Not tainted 4.9.302-00032-g64e078a56789 #13476 +| Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Jul 30 2018 +| Call trace: +| [] dump_backtrace+0x0/0x1a0 +| [] show_stack+0x14/0x20 +| [] dump_stack+0x98/0xb8 +| [] panic+0x118/0x274 +| [] access_actlr+0x0/0x20 +| [] kvm_reset_vcpu+0x5c/0xac +| [] kvm_arch_vcpu_ioctl+0x3e4/0x490 +| [] kvm_vcpu_ioctl+0x5b8/0x720 +| [] do_vfs_ioctl+0x2f4/0x884 +| [] SyS_ioctl+0x78/0x9c +| [] __sys_trace_return+0x0/0x4 + +Cc: # < v5.3 with 2a5f1b67ec57 backported +Signed-off-by: James Morse +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/kvm/sys_regs.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/arch/arm64/kvm/sys_regs.c ++++ b/arch/arm64/kvm/sys_regs.c +@@ -451,8 +451,10 @@ static void reset_pmcr(struct kvm_vcpu * + u64 pmcr, val; + + /* No PMU available, PMCR_EL0 may UNDEF... */ +- if (!kvm_arm_support_pmu_v3()) ++ if (!kvm_arm_support_pmu_v3()) { ++ vcpu_sys_reg(vcpu, PMCR_EL0) = 0; + return; ++ } + + pmcr = read_sysreg(pmcr_el0); + /* diff --git a/queue-4.9/series b/queue-4.9/series index b3bcfda755e..19f2fdbdbb7 100644 --- a/queue-4.9/series +++ b/queue-4.9/series @@ -12,3 +12,5 @@ revert-xen-netback-check-for-hotplug-status-existenc.patch tracing-ensure-trace-buffer-is-at-least-4096-bytes-l.patch selftests-memfd-clean-up-mapping-in-mfd_fail_write.patch arm-spectre-bhb-provide-empty-stub-for-non-config.patch +staging-gdm724x-fix-use-after-free-in-gdm_lte_rx.patch +kvm-arm64-reset-pmc_el0-to-avoid-a-panic-on-systems-with-no-pmu.patch diff --git a/queue-4.9/staging-gdm724x-fix-use-after-free-in-gdm_lte_rx.patch b/queue-4.9/staging-gdm724x-fix-use-after-free-in-gdm_lte_rx.patch new file mode 100644 index 00000000000..cb8ae0cd09d --- /dev/null +++ b/queue-4.9/staging-gdm724x-fix-use-after-free-in-gdm_lte_rx.patch @@ -0,0 +1,42 @@ +From fc7f750dc9d102c1ed7bbe4591f991e770c99033 Mon Sep 17 00:00:00 2001 +From: Dan Carpenter +Date: Mon, 28 Feb 2022 10:43:31 +0300 +Subject: staging: gdm724x: fix use after free in gdm_lte_rx() + +From: Dan Carpenter + +commit fc7f750dc9d102c1ed7bbe4591f991e770c99033 upstream. + +The netif_rx_ni() function frees the skb so we can't dereference it to +save the skb->len. + +Fixes: 61e121047645 ("staging: gdm7240: adding LTE USB driver") +Cc: stable +Reported-by: kernel test robot +Signed-off-by: Dan Carpenter +Link: https://lore.kernel.org/r/20220228074331.GA13685@kili +Signed-off-by: Greg Kroah-Hartman +--- + drivers/staging/gdm724x/gdm_lte.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +--- a/drivers/staging/gdm724x/gdm_lte.c ++++ b/drivers/staging/gdm724x/gdm_lte.c +@@ -85,14 +85,15 @@ static void tx_complete(void *arg) + + static int gdm_lte_rx(struct sk_buff *skb, struct nic *nic, int nic_type) + { +- int ret; ++ int ret, len; + ++ len = skb->len + ETH_HLEN; + ret = netif_rx_ni(skb); + if (ret == NET_RX_DROP) { + nic->stats.rx_dropped++; + } else { + nic->stats.rx_packets++; +- nic->stats.rx_bytes += skb->len + ETH_HLEN; ++ nic->stats.rx_bytes += len; + } + + return 0;