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 (file)
index 0000000..9f8d2ae
--- /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 <james.morse@arm.com>
+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 <maz@kernel.org>, Alexandru Elisei <alexandru.elisei@arm.com>, james.morse@arm.com
+Message-ID: <20220308162939.603335-1-james.morse@arm.com>
+
+From: James Morse <james.morse@arm.com>
+
+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:
+| [<ffff00000808b4b0>] dump_backtrace+0x0/0x1a0
+| [<ffff00000808b664>] show_stack+0x14/0x20
+| [<ffff0000088f0e18>] dump_stack+0x98/0xb8
+| [<ffff0000088eef08>] panic+0x118/0x274
+| [<ffff0000080b50e0>] access_actlr+0x0/0x20
+| [<ffff0000080b2620>] kvm_reset_vcpu+0x5c/0xac
+| [<ffff0000080ac688>] kvm_arch_vcpu_ioctl+0x3e4/0x490
+| [<ffff0000080a382c>] kvm_vcpu_ioctl+0x5b8/0x720
+| [<ffff000008201e44>] do_vfs_ioctl+0x2f4/0x884
+| [<ffff00000820244c>] SyS_ioctl+0x78/0x9c
+| [<ffff000008083a9c>] __sys_trace_return+0x0/0x4
+
+Cc: <stable@vger.kernel.org> # < v5.3 with 2a5f1b67ec57 backported
+Signed-off-by: James Morse <james.morse@arm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 b3bcfda755e5b0da87d6d7a34670ee641dd4ded0..19f2fdbdbb7e9b1383ed0050b77901e3a340ee62 100644 (file)
--- 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 (file)
index 0000000..cb8ae0c
--- /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 <dan.carpenter@oracle.com>
+Date: Mon, 28 Feb 2022 10:43:31 +0300
+Subject: staging: gdm724x: fix use after free in gdm_lte_rx()
+
+From: Dan Carpenter <dan.carpenter@oracle.com>
+
+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 <stable@vger.kernel.org>
+Reported-by: kernel test robot <lkp@intel.com>
+Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
+Link: https://lore.kernel.org/r/20220228074331.GA13685@kili
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;