October 2019 - Linux-stable-mirror

[PATCH for-stable-v4.19 00/16] arm64 spec mitigation backports

by Ard Biesheuvel

This is a backport to v4.19 of the arm64 patches that exists in mainline to support CPUs that implement the SSBS capability, which gives the OS and user space control over whether Speculative Store Bypass is permitted in certain contexts. This gives a substantial performance boost on hardware that implements it. At the same time, this series backports arm64 support for reporting of vulnerabilities via syfs. This is covered by the same series since it produces a much cleaner backport, where none of the patches required any changes beyond some manual mangling of the context to make them apply. Build tested using a fair number of randconfig builds. Boot tested under KVM and on ThunderX2. Cc: Will Deacon <will(a)kernel.org> Cc: Catalin Marinas <catalin.marinas(a)arm.com> Cc: Marc Zyngier <maz(a)kernel.org> Cc: Mark Rutland <mark.rutland(a)arm.com> Cc: Suzuki K Poulose <suzuki.poulose(a)arm.com> Cc: Jeremy Linton <jeremy.linton(a)arm.com> Cc: Andre Przywara <andre.przywara(a)arm.com> Jeremy Linton (6): arm64: add sysfs vulnerability show for meltdown arm64: Always enable ssb vulnerability detection arm64: Provide a command line to disable spectre_v2 mitigation arm64: Always enable spectre-v2 vulnerability detection arm64: add sysfs vulnerability show for spectre-v2 arm64: add sysfs vulnerability show for speculative store bypass Marc Zyngier (2): arm64: Advertise mitigation of Spectre-v2, or lack thereof arm64: Force SSBS on context switch Mark Rutland (1): arm64: fix SSBS sanitization Mian Yousaf Kaukab (2): arm64: Add sysfs vulnerability show for spectre-v1 arm64: enable generic CPU vulnerabilites support Will Deacon (5): arm64: cpufeature: Detect SSBS and advertise to userspace arm64: ssbd: Add support for PSTATE.SSBS rather than trapping to EL3 KVM: arm64: Set SCTLR_EL2.DSSBS if SSBD is forcefully disabled and !vhe arm64: docs: Document SSBS HWCAP arm64: ssbs: Don't treat CPUs with SSBS as unaffected by SSB Documentation/admin-guide/kernel-parameters.txt | 8 +- Documentation/arm64/elf_hwcaps.txt | 4 + arch/arm64/Kconfig | 1 + arch/arm64/include/asm/cpucaps.h | 3 +- arch/arm64/include/asm/cpufeature.h | 4 - arch/arm64/include/asm/kvm_host.h | 11 + arch/arm64/include/asm/processor.h | 17 ++ arch/arm64/include/asm/ptrace.h | 1 + arch/arm64/include/asm/sysreg.h | 19 +- arch/arm64/include/uapi/asm/hwcap.h | 1 + arch/arm64/include/uapi/asm/ptrace.h | 1 + arch/arm64/kernel/cpu_errata.c | 235 +++++++++++++++----- arch/arm64/kernel/cpufeature.c | 122 ++++++++-- arch/arm64/kernel/cpuinfo.c | 1 + arch/arm64/kernel/process.c | 31 +++ arch/arm64/kernel/ptrace.c | 15 +- arch/arm64/kernel/ssbd.c | 21 ++ arch/arm64/kvm/hyp/sysreg-sr.c | 11 + 18 files changed, 410 insertions(+), 96 deletions(-) -- 2.20.1

5 years

2
18
0 0

[PATCH] pinctrl: armada-37xx: swap polarity on LED group

by Patrick Williams

The configuration registers for the LED group have inverted polarity, which puts the GPIO into open-drain state when used in GPIO mode. Switch to '0' for GPIO and '1' for LED modes. Fixes: 87466ccd9401 ("pinctrl: armada-37xx: Add pin controller support for Armada 37xx") Signed-off-by: Patrick Williams <alpawi(a)amazon.com> Cc: <stable(a)vger.kernel.org> --- drivers/pinctrl/mvebu/pinctrl-armada-37xx.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c b/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c index 6462d3ca7ceb..6310963ce5f0 100644 --- a/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c +++ b/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c @@ -183,10 +183,10 @@ static struct armada_37xx_pin_group armada_37xx_nb_groups[] = { PIN_GRP_EXTRA("uart2", 9, 2, BIT(1) | BIT(13) | BIT(14) | BIT(19), BIT(1) | BIT(13) | BIT(14), BIT(1) | BIT(19), 18, 2, "gpio", "uart"), - PIN_GRP_GPIO("led0_od", 11, 1, BIT(20), "led"), - PIN_GRP_GPIO("led1_od", 12, 1, BIT(21), "led"), - PIN_GRP_GPIO("led2_od", 13, 1, BIT(22), "led"), - PIN_GRP_GPIO("led3_od", 14, 1, BIT(23), "led"), + PIN_GRP_GPIO_2("led0_od", 11, 1, BIT(20), BIT(20), 0, "led"), + PIN_GRP_GPIO_2("led1_od", 12, 1, BIT(21), BIT(21), 0, "led"), + PIN_GRP_GPIO_2("led2_od", 13, 1, BIT(22), BIT(22), 0, "led"), + PIN_GRP_GPIO_2("led3_od", 14, 1, BIT(23), BIT(23), 0, "led"), }; -- 2.17.2 (Apple Git-113)

5 years

2
1
0 0

FAILED: patch "[PATCH] KVM: nVMX: Fix consistency check on injected exception error" failed to apply to 5.3-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.3-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 567926cca99ba1750be8aae9c4178796bf9bb90b Mon Sep 17 00:00:00 2001 From: Sean Christopherson <sean.j.christopherson(a)intel.com> Date: Tue, 1 Oct 2019 09:21:23 -0700 Subject: [PATCH] KVM: nVMX: Fix consistency check on injected exception error code Current versions of Intel's SDM incorrectly state that "bits 31:15 of the VM-Entry exception error-code field" must be zero. In reality, bits 31:16 must be zero, i.e. error codes are 16-bit values. The bogus error code check manifests as an unexpected VM-Entry failure due to an invalid code field (error number 7) in L1, e.g. when injecting a #GP with error_code=0x9f00. Nadav previously reported the bug[*], both to KVM and Intel, and fixed the associated kvm-unit-test. [*] https://patchwork.kernel.org/patch/11124749/ Reported-by: Nadav Amit <namit(a)vmware.com> Cc: stable(a)vger.kernel.org Signed-off-by: Sean Christopherson <sean.j.christopherson(a)intel.com> Reviewed-by: Jim Mattson <jmattson(a)google.com> Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c index 41abc62c9a8a..e76eb4f07f6c 100644 --- a/arch/x86/kvm/vmx/nested.c +++ b/arch/x86/kvm/vmx/nested.c @@ -2610,7 +2610,7 @@ static int nested_check_vm_entry_controls(struct kvm_vcpu *vcpu, /* VM-entry exception error code */ if (CC(has_error_code && - vmcs12->vm_entry_exception_error_code & GENMASK(31, 15))) + vmcs12->vm_entry_exception_error_code & GENMASK(31, 16))) return -EINVAL; /* VM-entry interruption-info field: reserved bits */

5 years

3
2
0 0

FAILED: patch "[PATCH] KVM: PPC: Book3S HV: XIVE: Free escalation interrupts before" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 237aed48c642328ff0ab19b63423634340224a06 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?C=C3=A9dric=20Le=20Goater?= <clg(a)kaod.org> Date: Tue, 6 Aug 2019 19:25:38 +0200 Subject: [PATCH] KVM: PPC: Book3S HV: XIVE: Free escalation interrupts before disabling the VP MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit When a vCPU is brought done, the XIVE VP (Virtual Processor) is first disabled and then the event notification queues are freed. When freeing the queues, we check for possible escalation interrupts and free them also. But when a XIVE VP is disabled, the underlying XIVE ENDs also are disabled in OPAL. When an END (Event Notification Descriptor) is disabled, its ESB pages (ESn and ESe) are disabled and loads return all 1s. Which means that any access on the ESB page of the escalation interrupt will return invalid values. When an interrupt is freed, the shutdown handler computes a 'saved_p' field from the value returned by a load in xive_do_source_set_mask(). This value is incorrect for escalation interrupts for the reason described above. This has no impact on Linux/KVM today because we don't make use of it but we will introduce in future changes a xive_get_irqchip_state() handler. This handler will use the 'saved_p' field to return the state of an interrupt and 'saved_p' being incorrect, softlockup will occur. Fix the vCPU cleanup sequence by first freeing the escalation interrupts if any, then disable the XIVE VP and last free the queues. Fixes: 90c73795afa2 ("KVM: PPC: Book3S HV: Add a new KVM device for the XIVE native exploitation mode") Fixes: 5af50993850a ("KVM: PPC: Book3S HV: Native usage of the XIVE interrupt controller") Cc: stable(a)vger.kernel.org # v4.12+ Signed-off-by: Cédric Le Goater <clg(a)kaod.org> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Link: https://lore.kernel.org/r/20190806172538.5087-1-clg@kaod.org diff --git a/arch/powerpc/kvm/book3s_xive.c b/arch/powerpc/kvm/book3s_xive.c index e3ba67095895..09f838aa3138 100644 --- a/arch/powerpc/kvm/book3s_xive.c +++ b/arch/powerpc/kvm/book3s_xive.c @@ -1134,20 +1134,22 @@ void kvmppc_xive_cleanup_vcpu(struct kvm_vcpu *vcpu) /* Mask the VP IPI */ xive_vm_esb_load(&xc->vp_ipi_data, XIVE_ESB_SET_PQ_01); - /* Disable the VP */ - xive_native_disable_vp(xc->vp_id); - - /* Free the queues & associated interrupts */ + /* Free escalations */ for (i = 0; i < KVMPPC_XIVE_Q_COUNT; i++) { - struct xive_q *q = &xc->queues[i]; - - /* Free the escalation irq */ if (xc->esc_virq[i]) { free_irq(xc->esc_virq[i], vcpu); irq_dispose_mapping(xc->esc_virq[i]); kfree(xc->esc_virq_names[i]); } - /* Free the queue */ + } + + /* Disable the VP */ + xive_native_disable_vp(xc->vp_id); + + /* Free the queues */ + for (i = 0; i < KVMPPC_XIVE_Q_COUNT; i++) { + struct xive_q *q = &xc->queues[i]; + xive_native_disable_queue(xc->vp_id, q, i); if (q->qpage) { free_pages((unsigned long)q->qpage, diff --git a/arch/powerpc/kvm/book3s_xive_native.c b/arch/powerpc/kvm/book3s_xive_native.c index a998823f68a3..368427fcad20 100644 --- a/arch/powerpc/kvm/book3s_xive_native.c +++ b/arch/powerpc/kvm/book3s_xive_native.c @@ -67,10 +67,7 @@ void kvmppc_xive_native_cleanup_vcpu(struct kvm_vcpu *vcpu) xc->valid = false; kvmppc_xive_disable_vcpu_interrupts(vcpu); - /* Disable the VP */ - xive_native_disable_vp(xc->vp_id); - - /* Free the queues & associated interrupts */ + /* Free escalations */ for (i = 0; i < KVMPPC_XIVE_Q_COUNT; i++) { /* Free the escalation irq */ if (xc->esc_virq[i]) { @@ -79,8 +76,13 @@ void kvmppc_xive_native_cleanup_vcpu(struct kvm_vcpu *vcpu) kfree(xc->esc_virq_names[i]); xc->esc_virq[i] = 0; } + } - /* Free the queue */ + /* Disable the VP */ + xive_native_disable_vp(xc->vp_id); + + /* Free the queues */ + for (i = 0; i < KVMPPC_XIVE_Q_COUNT; i++) { kvmppc_xive_native_cleanup_queue(vcpu, i); }

5 years

3
2
0 0

[PATCH AUTOSEL 5.3 01/71] drivers: thermal: qcom: tsens: Fix memory leak from qfprom read

by Sasha Levin

From: Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org> [ Upstream commit 6b8249abb093551ef173d13a25ed0044d5dd33e0 ] memory returned as part of nvmem_read via qfprom_read should be freed by the consumer once done. Existing code is not doing it so fix it. Below memory leak detected by kmemleak [<ffffff80088b7658>] kmemleak_alloc+0x50/0x84 [<ffffff80081df120>] __kmalloc+0xe8/0x168 [<ffffff80086db350>] nvmem_cell_read+0x30/0x80 [<ffffff8008632790>] qfprom_read+0x4c/0x7c [<ffffff80086335a4>] calibrate_v1+0x34/0x204 [<ffffff8008632518>] tsens_probe+0x164/0x258 [<ffffff80084e0a1c>] platform_drv_probe+0x80/0xa0 [<ffffff80084de4f4>] really_probe+0x208/0x248 [<ffffff80084de2c4>] driver_probe_device+0x98/0xc0 [<ffffff80084dec54>] __device_attach_driver+0x9c/0xac [<ffffff80084dca74>] bus_for_each_drv+0x60/0x8c [<ffffff80084de634>] __device_attach+0x8c/0x100 [<ffffff80084de6c8>] device_initial_probe+0x20/0x28 [<ffffff80084dcbb8>] bus_probe_device+0x34/0x7c [<ffffff80084deb08>] deferred_probe_work_func+0x6c/0x98 [<ffffff80080c3da8>] process_one_work+0x160/0x2f8 Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org> Acked-by: Amit Kucheria <amit.kucheria(a)linaro.org> Signed-off-by: Zhang Rui <rui.zhang(a)intel.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/thermal/qcom/tsens-8960.c | 2 ++ drivers/thermal/qcom/tsens-v0_1.c | 12 ++++++++++-- drivers/thermal/qcom/tsens-v1.c | 1 + drivers/thermal/qcom/tsens.h | 1 + 4 files changed, 14 insertions(+), 2 deletions(-) diff --git a/drivers/thermal/qcom/tsens-8960.c b/drivers/thermal/qcom/tsens-8960.c index 8d9b721dadb65..e46a4e3f25c42 100644 --- a/drivers/thermal/qcom/tsens-8960.c +++ b/drivers/thermal/qcom/tsens-8960.c @@ -229,6 +229,8 @@ static int calibrate_8960(struct tsens_priv *priv) for (i = 0; i < num_read; i++, s++) s->offset = data[i]; + kfree(data); + return 0; } diff --git a/drivers/thermal/qcom/tsens-v0_1.c b/drivers/thermal/qcom/tsens-v0_1.c index 6f26fadf4c279..055647bcee67d 100644 --- a/drivers/thermal/qcom/tsens-v0_1.c +++ b/drivers/thermal/qcom/tsens-v0_1.c @@ -145,8 +145,10 @@ static int calibrate_8916(struct tsens_priv *priv) return PTR_ERR(qfprom_cdata); qfprom_csel = (u32 *)qfprom_read(priv->dev, "calib_sel"); - if (IS_ERR(qfprom_csel)) + if (IS_ERR(qfprom_csel)) { + kfree(qfprom_cdata); return PTR_ERR(qfprom_csel); + } mode = (qfprom_csel[0] & MSM8916_CAL_SEL_MASK) >> MSM8916_CAL_SEL_SHIFT; dev_dbg(priv->dev, "calibration mode is %d\n", mode); @@ -181,6 +183,8 @@ static int calibrate_8916(struct tsens_priv *priv) } compute_intercept_slope(priv, p1, p2, mode); + kfree(qfprom_cdata); + kfree(qfprom_csel); return 0; } @@ -198,8 +202,10 @@ static int calibrate_8974(struct tsens_priv *priv) return PTR_ERR(calib); bkp = (u32 *)qfprom_read(priv->dev, "calib_backup"); - if (IS_ERR(bkp)) + if (IS_ERR(bkp)) { + kfree(calib); return PTR_ERR(bkp); + } calib_redun_sel = bkp[1] & BKP_REDUN_SEL; calib_redun_sel >>= BKP_REDUN_SHIFT; @@ -313,6 +319,8 @@ static int calibrate_8974(struct tsens_priv *priv) } compute_intercept_slope(priv, p1, p2, mode); + kfree(calib); + kfree(bkp); return 0; } diff --git a/drivers/thermal/qcom/tsens-v1.c b/drivers/thermal/qcom/tsens-v1.c index 10b595d4f6199..870f502f2cb6c 100644 --- a/drivers/thermal/qcom/tsens-v1.c +++ b/drivers/thermal/qcom/tsens-v1.c @@ -138,6 +138,7 @@ static int calibrate_v1(struct tsens_priv *priv) } compute_intercept_slope(priv, p1, p2, mode); + kfree(qfprom_cdata); return 0; } diff --git a/drivers/thermal/qcom/tsens.h b/drivers/thermal/qcom/tsens.h index 2fd94997245bf..b89083b61c383 100644 --- a/drivers/thermal/qcom/tsens.h +++ b/drivers/thermal/qcom/tsens.h @@ -17,6 +17,7 @@ #include <linux/thermal.h> #include <linux/regmap.h> +#include <linux/slab.h> struct tsens_priv; -- 2.20.1

5 years

3
73
0 0

[PATCH] PCI: rcar: Fix writing the MACCTLR register value

by Yoshihiro Shimoda

According to the R-Car Gen2/3 manual, the bit 0 of MACCTLR register should be written by 0. To avoid unexpected behaviors from this incorrect setting, this patch fixes it. Fixes: b3327f7fae66 ("PCI: rcar: Try increasing PCIe link speed to 5 GT/s at boot") Cc: <stable(a)vger.kernel.org> # v4.9+ Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com> --- drivers/pci/controller/pcie-rcar.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/pci/controller/pcie-rcar.c b/drivers/pci/controller/pcie-rcar.c index f6a669a..9eb9b25 100644 --- a/drivers/pci/controller/pcie-rcar.c +++ b/drivers/pci/controller/pcie-rcar.c @@ -93,6 +93,7 @@ #define LINK_SPEED_2_5GTS (1 << 16) #define LINK_SPEED_5_0GTS (2 << 16) #define MACCTLR 0x011058 +#define MACCTLR_RESERVED BIT(0) #define SPEED_CHANGE BIT(24) #define SCRAMBLE_DISABLE BIT(27) #define PMSR 0x01105c @@ -427,7 +428,8 @@ static void rcar_pcie_force_speedup(struct rcar_pcie *pcie) rcar_pci_write_reg(pcie, macsr, MACSR); /* Start link speed change */ - rcar_rmw32(pcie, MACCTLR, SPEED_CHANGE, SPEED_CHANGE); + rcar_rmw32(pcie, MACCTLR, SPEED_CHANGE | MACCTLR_RESERVED, + SPEED_CHANGE); while (timeout--) { macsr = rcar_pci_read_reg(pcie, MACSR); -- 2.7.4

5 years

2
2
0 0

FAILED: patch "[PATCH] riscv: Avoid interrupts being erroneously enabled in" failed to apply to 5.3-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.3-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From c82dd6d078a2bb29d41eda032bb96d05699a524d Mon Sep 17 00:00:00 2001 From: Vincent Chen <vincent.chen(a)sifive.com> Date: Mon, 16 Sep 2019 16:47:41 +0800 Subject: [PATCH] riscv: Avoid interrupts being erroneously enabled in handle_exception() When the handle_exception function addresses an exception, the interrupts will be unconditionally enabled after finishing the context save. However, It may erroneously enable the interrupts if the interrupts are disabled before entering the handle_exception. For example, one of the WARN_ON() condition is satisfied in the scheduling where the interrupt is disabled and rq.lock is locked. The WARN_ON will trigger a break exception and the handle_exception function will enable the interrupts before entering do_trap_break function. During the procedure, if a timer interrupt is pending, it will be taken when interrupts are enabled. In this case, it may cause a deadlock problem if the rq.lock is locked again in the timer ISR. Hence, the handle_exception() can only enable interrupts when the state of sstatus.SPIE is 1. This patch is tested on HiFive Unleashed board. Signed-off-by: Vincent Chen <vincent.chen(a)sifive.com> Reviewed-by: Palmer Dabbelt <palmer(a)sifive.com> [paul.walmsley(a)sifive.com: updated to apply] Fixes: bcae803a21317 ("RISC-V: Enable IRQ during exception handling") Cc: David Abdurachmanov <david.abdurachmanov(a)sifive.com> Cc: stable(a)vger.kernel.org Signed-off-by: Paul Walmsley <paul.walmsley(a)sifive.com> diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S index 74ccfd464071..da7aa88113c2 100644 --- a/arch/riscv/kernel/entry.S +++ b/arch/riscv/kernel/entry.S @@ -166,9 +166,13 @@ ENTRY(handle_exception) move a0, sp /* pt_regs */ tail do_IRQ 1: - /* Exceptions run with interrupts enabled */ + /* Exceptions run with interrupts enabled or disabled + depending on the state of sstatus.SR_SPIE */ + andi t0, s1, SR_SPIE + beqz t0, 1f csrs CSR_SSTATUS, SR_SIE +1: /* Handle syscalls */ li t0, EXC_SYSCALL beq s4, t0, handle_syscall

5 years

3
4
0 0

[PATCH v2 6/6] rpmsg: glink: Free pending deferred work on remove

by Bjorn Andersson

By just cancelling the deferred rx worker during GLINK instance teardown any pending deferred commands are leaked, so free them. Fixes: b4f8e52b89f6 ("rpmsg: Introduce Qualcomm RPM glink driver") Cc: stable(a)vger.kernel.org Tested-by: Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson(a)linaro.org> --- Changes since v1: - None drivers/rpmsg/qcom_glink_native.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/drivers/rpmsg/qcom_glink_native.c b/drivers/rpmsg/qcom_glink_native.c index 4117818db6a1..862f89c128a0 100644 --- a/drivers/rpmsg/qcom_glink_native.c +++ b/drivers/rpmsg/qcom_glink_native.c @@ -1562,6 +1562,18 @@ static void qcom_glink_work(struct work_struct *work) } } +static void qcom_glink_cancel_rx_work(struct qcom_glink *glink) +{ + struct glink_defer_cmd *dcmd; + struct glink_defer_cmd *tmp; + + /* cancel any pending deferred rx_work */ + cancel_work_sync(&glink->rx_work); + + list_for_each_entry_safe(dcmd, tmp, &glink->rx_queue, node) + kfree(dcmd); +} + struct qcom_glink *qcom_glink_native_probe(struct device *dev, unsigned long features, struct qcom_glink_pipe *rx, @@ -1640,7 +1652,7 @@ void qcom_glink_native_remove(struct qcom_glink *glink) unsigned long flags; disable_irq(glink->irq); - cancel_work_sync(&glink->rx_work); + qcom_glink_cancel_rx_work(glink); ret = device_for_each_child(glink->dev, NULL, qcom_glink_remove_device); if (ret) -- 2.18.0

5 years

2
1
0 0

[PATCH v2 5/6] rpmsg: glink: Don't send pending rx_done during remove

by Bjorn Andersson

Attempting to transmit rx_done messages after the GLINK instance is being torn down will cause use after free and memory leaks. So cancel the intent_work and free up the pending intents. With this there are no concurrent accessors of the channel left during qcom_glink_native_remove() and there is therefor no need to hold the spinlock during this operation - which would prohibit the use of cancel_work_sync() in the release function. So remove this. Fixes: 1d2ea36eead9 ("rpmsg: glink: Add rx done command") Cc: stable(a)vger.kernel.org Tested-by: Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson(a)linaro.org> --- Changes since v1: - Drop the locking of idr_lock in qcom_glink_native_remove() drivers/rpmsg/qcom_glink_native.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/drivers/rpmsg/qcom_glink_native.c b/drivers/rpmsg/qcom_glink_native.c index 89e02baea2d0..4117818db6a1 100644 --- a/drivers/rpmsg/qcom_glink_native.c +++ b/drivers/rpmsg/qcom_glink_native.c @@ -241,11 +241,23 @@ static void qcom_glink_channel_release(struct kref *ref) { struct glink_channel *channel = container_of(ref, struct glink_channel, refcount); + struct glink_core_rx_intent *intent; struct glink_core_rx_intent *tmp; unsigned long flags; int iid; + /* cancel pending rx_done work */ + cancel_work_sync(&channel->intent_work); + spin_lock_irqsave(&channel->intent_lock, flags); + /* Free all non-reuse intents pending rx_done work */ + list_for_each_entry_safe(intent, tmp, &channel->done_intents, node) { + if (!intent->reuse) { + kfree(intent->data); + kfree(intent); + } + } + idr_for_each_entry(&channel->liids, tmp, iid) { kfree(tmp->data); kfree(tmp); @@ -1634,7 +1646,6 @@ void qcom_glink_native_remove(struct qcom_glink *glink) if (ret) dev_warn(glink->dev, "Can't remove GLINK devices: %d\n", ret); - spin_lock_irqsave(&glink->idr_lock, flags); /* Release any defunct local channels, waiting for close-ack */ idr_for_each_entry(&glink->lcids, channel, cid) kref_put(&channel->refcount, qcom_glink_channel_release); @@ -1645,7 +1656,6 @@ void qcom_glink_native_remove(struct qcom_glink *glink) idr_destroy(&glink->lcids); idr_destroy(&glink->rcids); - spin_unlock_irqrestore(&glink->idr_lock, flags); mbox_free_channel(glink->mbox_chan); } EXPORT_SYMBOL_GPL(qcom_glink_native_remove); -- 2.18.0

5 years

2
1
0 0

[PATCH v2 2/6] rpmsg: glink: Fix use after free in open_ack TIMEOUT case

by Bjorn Andersson

From: Arun Kumar Neelakantam <aneela(a)codeaurora.org> Extra channel reference put when remote sending OPEN_ACK after timeout causes use-after-free while handling next remote CLOSE command. Remove extra reference put in timeout case to avoid use-after-free. Fixes: b4f8e52b89f6 ("rpmsg: Introduce Qualcomm RPM glink driver") Cc: stable(a)vger.kernel.org Tested-by: Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org> Signed-off-by: Arun Kumar Neelakantam <aneela(a)codeaurora.org> Signed-off-by: Bjorn Andersson <bjorn.andersson(a)linaro.org> --- Changes since v1: - None drivers/rpmsg/qcom_glink_native.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/rpmsg/qcom_glink_native.c b/drivers/rpmsg/qcom_glink_native.c index 9355ce26fd98..72ed671f5dcd 100644 --- a/drivers/rpmsg/qcom_glink_native.c +++ b/drivers/rpmsg/qcom_glink_native.c @@ -1103,13 +1103,12 @@ static int qcom_glink_create_remote(struct qcom_glink *glink, close_link: /* * Send a close request to "undo" our open-ack. The close-ack will - * release the last reference. + * release qcom_glink_send_open_req() reference and the last reference + * will be relesed after receiving remote_close or transport unregister + * by calling qcom_glink_native_remove(). */ qcom_glink_send_close_req(glink, channel); - /* Release qcom_glink_send_open_req() reference */ - kref_put(&channel->refcount, qcom_glink_channel_release); - return ret; } -- 2.18.0

5 years

2
1
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror October 2019