From: Greg Kroah-Hartman Date: Mon, 11 Apr 2022 08:27:09 +0000 (+0200) Subject: 5.10-stable patches X-Git-Tag: v4.9.310~67 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=cd5368c8dc271df1c053bcaf0c35391d6e635328;p=thirdparty%2Fkernel%2Fstable-queue.git 5.10-stable patches added patches: arm64-patch_text-fixup-last-cpu-should-be-master.patch ata-sata_dwc_460ex-fix-crash-due-to-oob-write.patch gpio-restrict-usage-of-gpio-chip-irq-members-before-initialization.patch irqchip-gic-v3-fix-gicr_ctlr.rwp-polling.patch perf-qcom_l2_pmu-fix-an-incorrect-null-check-on-list-iterator.patch rdma-hfi1-fix-use-after-free-bug-for-mm-struct.patch --- diff --git a/queue-5.10/arm64-patch_text-fixup-last-cpu-should-be-master.patch b/queue-5.10/arm64-patch_text-fixup-last-cpu-should-be-master.patch new file mode 100644 index 00000000000..93a1c20ebe2 --- /dev/null +++ b/queue-5.10/arm64-patch_text-fixup-last-cpu-should-be-master.patch @@ -0,0 +1,42 @@ +From 31a099dbd91e69fcab55eef4be15ed7a8c984918 Mon Sep 17 00:00:00 2001 +From: Guo Ren +Date: Thu, 7 Apr 2022 15:33:20 +0800 +Subject: arm64: patch_text: Fixup last cpu should be master + +From: Guo Ren + +commit 31a099dbd91e69fcab55eef4be15ed7a8c984918 upstream. + +These patch_text implementations are using stop_machine_cpuslocked +infrastructure with atomic cpu_count. The original idea: When the +master CPU patch_text, the others should wait for it. But current +implementation is using the first CPU as master, which couldn't +guarantee the remaining CPUs are waiting. This patch changes the +last CPU as the master to solve the potential risk. + +Fixes: ae16480785de ("arm64: introduce interfaces to hotpatch kernel and module code") +Signed-off-by: Guo Ren +Signed-off-by: Guo Ren +Reviewed-by: Catalin Marinas +Reviewed-by: Masami Hiramatsu +Cc: +Link: https://lore.kernel.org/r/20220407073323.743224-2-guoren@kernel.org +Signed-off-by: Will Deacon +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/kernel/insn.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/arch/arm64/kernel/insn.c ++++ b/arch/arm64/kernel/insn.c +@@ -216,8 +216,8 @@ static int __kprobes aarch64_insn_patch_ + int i, ret = 0; + struct aarch64_insn_patch *pp = arg; + +- /* The first CPU becomes master */ +- if (atomic_inc_return(&pp->cpu_count) == 1) { ++ /* The last CPU becomes master */ ++ if (atomic_inc_return(&pp->cpu_count) == num_online_cpus()) { + for (i = 0; ret == 0 && i < pp->insn_cnt; i++) + ret = aarch64_insn_patch_text_nosync(pp->text_addrs[i], + pp->new_insns[i]); diff --git a/queue-5.10/ata-sata_dwc_460ex-fix-crash-due-to-oob-write.patch b/queue-5.10/ata-sata_dwc_460ex-fix-crash-due-to-oob-write.patch new file mode 100644 index 00000000000..818bc831b76 --- /dev/null +++ b/queue-5.10/ata-sata_dwc_460ex-fix-crash-due-to-oob-write.patch @@ -0,0 +1,83 @@ +From 7aa8104a554713b685db729e66511b93d989dd6a Mon Sep 17 00:00:00 2001 +From: Christian Lamparter +Date: Sat, 19 Mar 2022 21:11:02 +0100 +Subject: ata: sata_dwc_460ex: Fix crash due to OOB write + +From: Christian Lamparter + +commit 7aa8104a554713b685db729e66511b93d989dd6a upstream. + +the driver uses libata's "tag" values from in various arrays. +Since the mentioned patch bumped the ATA_TAG_INTERNAL to 32, +the value of the SATA_DWC_QCMD_MAX needs to account for that. + +Otherwise ATA_TAG_INTERNAL usage cause similar crashes like +this as reported by Tice Rex on the OpenWrt Forum and +reproduced (with symbols) here: + +| BUG: Kernel NULL pointer dereference at 0x00000000 +| Faulting instruction address: 0xc03ed4b8 +| Oops: Kernel access of bad area, sig: 11 [#1] +| BE PAGE_SIZE=4K PowerPC 44x Platform +| CPU: 0 PID: 362 Comm: scsi_eh_1 Not tainted 5.4.163 #0 +| NIP: c03ed4b8 LR: c03d27e8 CTR: c03ed36c +| REGS: cfa59950 TRAP: 0300 Not tainted (5.4.163) +| MSR: 00021000 CR: 42000222 XER: 00000000 +| DEAR: 00000000 ESR: 00000000 +| GPR00: c03d27e8 cfa59a08 cfa55fe0 00000000 0fa46bc0 [...] +| [..] +| NIP [c03ed4b8] sata_dwc_qc_issue+0x14c/0x254 +| LR [c03d27e8] ata_qc_issue+0x1c8/0x2dc +| Call Trace: +| [cfa59a08] [c003f4e0] __cancel_work_timer+0x124/0x194 (unreliable) +| [cfa59a78] [c03d27e8] ata_qc_issue+0x1c8/0x2dc +| [cfa59a98] [c03d2b3c] ata_exec_internal_sg+0x240/0x524 +| [cfa59b08] [c03d2e98] ata_exec_internal+0x78/0xe0 +| [cfa59b58] [c03d30fc] ata_read_log_page.part.38+0x1dc/0x204 +| [cfa59bc8] [c03d324c] ata_identify_page_supported+0x68/0x130 +| [...] + +This is because sata_dwc_dma_xfer_complete() NULLs the +dma_pending's next neighbour "chan" (a *dma_chan struct) in +this '32' case right here (line ~735): +> hsdevp->dma_pending[tag] = SATA_DWC_DMA_PENDING_NONE; + +Then the next time, a dma gets issued; dma_dwc_xfer_setup() passes +the NULL'd hsdevp->chan to the dmaengine_slave_config() which then +causes the crash. + +With this patch, SATA_DWC_QCMD_MAX is now set to ATA_MAX_QUEUE + 1. +This avoids the OOB. But please note, there was a worthwhile discussion +on what ATA_TAG_INTERNAL and ATA_MAX_QUEUE is. And why there should not +be a "fake" 33 command-long queue size. + +Ideally, the dw driver should account for the ATA_TAG_INTERNAL. +In Damien Le Moal's words: "... having looked at the driver, it +is a bigger change than just faking a 33rd "tag" that is in fact +not a command tag at all." + +Fixes: 28361c403683c ("libata: add extra internal command") +Cc: stable@kernel.org # 4.18+ +BugLink: https://github.com/openwrt/openwrt/issues/9505 +Signed-off-by: Christian Lamparter +Signed-off-by: Damien Le Moal +Signed-off-by: Greg Kroah-Hartman +--- + drivers/ata/sata_dwc_460ex.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +--- a/drivers/ata/sata_dwc_460ex.c ++++ b/drivers/ata/sata_dwc_460ex.c +@@ -145,7 +145,11 @@ struct sata_dwc_device { + #endif + }; + +-#define SATA_DWC_QCMD_MAX 32 ++/* ++ * Allow one extra special slot for commands and DMA management ++ * to account for libata internal commands. ++ */ ++#define SATA_DWC_QCMD_MAX (ATA_MAX_QUEUE + 1) + + struct sata_dwc_device_port { + struct sata_dwc_device *hsdev; diff --git a/queue-5.10/gpio-restrict-usage-of-gpio-chip-irq-members-before-initialization.patch b/queue-5.10/gpio-restrict-usage-of-gpio-chip-irq-members-before-initialization.patch new file mode 100644 index 00000000000..a742e12db7e --- /dev/null +++ b/queue-5.10/gpio-restrict-usage-of-gpio-chip-irq-members-before-initialization.patch @@ -0,0 +1,94 @@ +From 5467801f1fcbdc46bc7298a84dbf3ca1ff2a7320 Mon Sep 17 00:00:00 2001 +From: Shreeya Patel +Date: Mon, 21 Mar 2022 19:02:41 +0530 +Subject: gpio: Restrict usage of GPIO chip irq members before initialization + +From: Shreeya Patel + +commit 5467801f1fcbdc46bc7298a84dbf3ca1ff2a7320 upstream. + +GPIO chip irq members are exposed before they could be completely +initialized and this leads to race conditions. + +One such issue was observed for the gc->irq.domain variable which +was accessed through the I2C interface in gpiochip_to_irq() before +it could be initialized by gpiochip_add_irqchip(). This resulted in +Kernel NULL pointer dereference. + +Following are the logs for reference :- + +kernel: Call Trace: +kernel: gpiod_to_irq+0x53/0x70 +kernel: acpi_dev_gpio_irq_get_by+0x113/0x1f0 +kernel: i2c_acpi_get_irq+0xc0/0xd0 +kernel: i2c_device_probe+0x28a/0x2a0 +kernel: really_probe+0xf2/0x460 +kernel: RIP: 0010:gpiochip_to_irq+0x47/0xc0 + +To avoid such scenarios, restrict usage of GPIO chip irq members before +they are completely initialized. + +Signed-off-by: Shreeya Patel +Cc: stable@vger.kernel.org +Reviewed-by: Andy Shevchenko +Reviewed-by: Linus Walleij +Signed-off-by: Bartosz Golaszewski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpio/gpiolib.c | 19 +++++++++++++++++++ + include/linux/gpio/driver.h | 9 +++++++++ + 2 files changed, 28 insertions(+) + +--- a/drivers/gpio/gpiolib.c ++++ b/drivers/gpio/gpiolib.c +@@ -1411,6 +1411,16 @@ static int gpiochip_to_irq(struct gpio_c + { + struct irq_domain *domain = gc->irq.domain; + ++#ifdef CONFIG_GPIOLIB_IRQCHIP ++ /* ++ * Avoid race condition with other code, which tries to lookup ++ * an IRQ before the irqchip has been properly registered, ++ * i.e. while gpiochip is still being brought up. ++ */ ++ if (!gc->irq.initialized) ++ return -EPROBE_DEFER; ++#endif ++ + if (!gpiochip_irqchip_irq_valid(gc, offset)) + return -ENXIO; + +@@ -1604,6 +1614,15 @@ static int gpiochip_add_irqchip(struct g + + acpi_gpiochip_request_interrupts(gc); + ++ /* ++ * Using barrier() here to prevent compiler from reordering ++ * gc->irq.initialized before initialization of above ++ * GPIO chip irq members. ++ */ ++ barrier(); ++ ++ gc->irq.initialized = true; ++ + return 0; + } + +--- a/include/linux/gpio/driver.h ++++ b/include/linux/gpio/driver.h +@@ -225,6 +225,15 @@ struct gpio_irq_chip { + unsigned int ngpios); + + /** ++ * @initialized: ++ * ++ * Flag to track GPIO chip irq member's initialization. ++ * This flag will make sure GPIO chip irq members are not used ++ * before they are initialized. ++ */ ++ bool initialized; ++ ++ /** + * @valid_mask: + * + * If not %NULL holds bitmask of GPIOs which are valid to be included diff --git a/queue-5.10/irqchip-gic-v3-fix-gicr_ctlr.rwp-polling.patch b/queue-5.10/irqchip-gic-v3-fix-gicr_ctlr.rwp-polling.patch new file mode 100644 index 00000000000..20ae1fba63b --- /dev/null +++ b/queue-5.10/irqchip-gic-v3-fix-gicr_ctlr.rwp-polling.patch @@ -0,0 +1,61 @@ +From 0df6664531a12cdd8fc873f0cac0dcb40243d3e9 Mon Sep 17 00:00:00 2001 +From: Marc Zyngier +Date: Tue, 15 Mar 2022 16:50:32 +0000 +Subject: irqchip/gic-v3: Fix GICR_CTLR.RWP polling + +From: Marc Zyngier + +commit 0df6664531a12cdd8fc873f0cac0dcb40243d3e9 upstream. + +It turns out that our polling of RWP is totally wrong when checking +for it in the redistributors, as we test the *distributor* bit index, +whereas it is a different bit number in the RDs... Oopsie boo. + +This is embarassing. Not only because it is wrong, but also because +it took *8 years* to notice the blunder... + +Just fix the damn thing. + +Fixes: 021f653791ad ("irqchip: gic-v3: Initial support for GICv3") +Signed-off-by: Marc Zyngier +Cc: stable@vger.kernel.org +Reviewed-by: Andre Przywara +Reviewed-by: Lorenzo Pieralisi +Link: https://lore.kernel.org/r/20220315165034.794482-2-maz@kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/irqchip/irq-gic-v3.c | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +--- a/drivers/irqchip/irq-gic-v3.c ++++ b/drivers/irqchip/irq-gic-v3.c +@@ -206,11 +206,11 @@ static inline void __iomem *gic_dist_bas + } + } + +-static void gic_do_wait_for_rwp(void __iomem *base) ++static void gic_do_wait_for_rwp(void __iomem *base, u32 bit) + { + u32 count = 1000000; /* 1s! */ + +- while (readl_relaxed(base + GICD_CTLR) & GICD_CTLR_RWP) { ++ while (readl_relaxed(base + GICD_CTLR) & bit) { + count--; + if (!count) { + pr_err_ratelimited("RWP timeout, gone fishing\n"); +@@ -224,13 +224,13 @@ static void gic_do_wait_for_rwp(void __i + /* Wait for completion of a distributor change */ + static void gic_dist_wait_for_rwp(void) + { +- gic_do_wait_for_rwp(gic_data.dist_base); ++ gic_do_wait_for_rwp(gic_data.dist_base, GICD_CTLR_RWP); + } + + /* Wait for completion of a redistributor change */ + static void gic_redist_wait_for_rwp(void) + { +- gic_do_wait_for_rwp(gic_data_rdist_rd_base()); ++ gic_do_wait_for_rwp(gic_data_rdist_rd_base(), GICR_CTLR_RWP); + } + + #ifdef CONFIG_ARM64 diff --git a/queue-5.10/perf-qcom_l2_pmu-fix-an-incorrect-null-check-on-list-iterator.patch b/queue-5.10/perf-qcom_l2_pmu-fix-an-incorrect-null-check-on-list-iterator.patch new file mode 100644 index 00000000000..fbcd5ba7561 --- /dev/null +++ b/queue-5.10/perf-qcom_l2_pmu-fix-an-incorrect-null-check-on-list-iterator.patch @@ -0,0 +1,53 @@ +From 2012a9e279013933885983cbe0a5fe828052563b Mon Sep 17 00:00:00 2001 +From: Xiaomeng Tong +Date: Sun, 27 Mar 2022 13:57:33 +0800 +Subject: perf: qcom_l2_pmu: fix an incorrect NULL check on list iterator + +From: Xiaomeng Tong + +commit 2012a9e279013933885983cbe0a5fe828052563b upstream. + +The bug is here: + return cluster; + +The list iterator value 'cluster' will *always* be set and non-NULL +by list_for_each_entry(), so it is incorrect to assume that the +iterator value will be NULL if the list is empty or no element +is found. + +To fix the bug, return 'cluster' when found, otherwise return NULL. + +Cc: stable@vger.kernel.org +Fixes: 21bdbb7102ed ("perf: add qcom l2 cache perf events driver") +Signed-off-by: Xiaomeng Tong +Link: https://lore.kernel.org/r/20220327055733.4070-1-xiam0nd.tong@gmail.com +Signed-off-by: Will Deacon +Signed-off-by: Greg Kroah-Hartman +--- + drivers/perf/qcom_l2_pmu.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/drivers/perf/qcom_l2_pmu.c ++++ b/drivers/perf/qcom_l2_pmu.c +@@ -739,7 +739,7 @@ static struct cluster_pmu *l2_cache_asso + { + u64 mpidr; + int cpu_cluster_id; +- struct cluster_pmu *cluster = NULL; ++ struct cluster_pmu *cluster; + + /* + * This assumes that the cluster_id is in MPIDR[aff1] for +@@ -761,10 +761,10 @@ static struct cluster_pmu *l2_cache_asso + cluster->cluster_id); + cpumask_set_cpu(cpu, &cluster->cluster_cpus); + *per_cpu_ptr(l2cache_pmu->pmu_cluster, cpu) = cluster; +- break; ++ return cluster; + } + +- return cluster; ++ return NULL; + } + + static int l2cache_pmu_online_cpu(unsigned int cpu, struct hlist_node *node) diff --git a/queue-5.10/rdma-hfi1-fix-use-after-free-bug-for-mm-struct.patch b/queue-5.10/rdma-hfi1-fix-use-after-free-bug-for-mm-struct.patch new file mode 100644 index 00000000000..fe9e3720d40 --- /dev/null +++ b/queue-5.10/rdma-hfi1-fix-use-after-free-bug-for-mm-struct.patch @@ -0,0 +1,51 @@ +From 2bbac98d0930e8161b1957dc0ec99de39ade1b3c Mon Sep 17 00:00:00 2001 +From: Douglas Miller +Date: Fri, 8 Apr 2022 09:35:23 -0400 +Subject: RDMA/hfi1: Fix use-after-free bug for mm struct + +From: Douglas Miller + +commit 2bbac98d0930e8161b1957dc0ec99de39ade1b3c upstream. + +Under certain conditions, such as MPI_Abort, the hfi1 cleanup code may +represent the last reference held on the task mm. +hfi1_mmu_rb_unregister() then drops the last reference and the mm is freed +before the final use in hfi1_release_user_pages(). A new task may +allocate the mm structure while it is still being used, resulting in +problems. One manifestation is corruption of the mmap_sem counter leading +to a hang in down_write(). Another is corruption of an mm struct that is +in use by another task. + +Fixes: 3d2a9d642512 ("IB/hfi1: Ensure correct mm is used at all times") +Link: https://lore.kernel.org/r/20220408133523.122165.72975.stgit@awfm-01.cornelisnetworks.com +Cc: +Signed-off-by: Douglas Miller +Signed-off-by: Dennis Dalessandro +Signed-off-by: Jason Gunthorpe +Signed-off-by: Greg Kroah-Hartman +--- + drivers/infiniband/hw/hfi1/mmu_rb.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +--- a/drivers/infiniband/hw/hfi1/mmu_rb.c ++++ b/drivers/infiniband/hw/hfi1/mmu_rb.c +@@ -121,6 +121,9 @@ void hfi1_mmu_rb_unregister(struct mmu_r + unsigned long flags; + struct list_head del_list; + ++ /* Prevent freeing of mm until we are completely finished. */ ++ mmgrab(handler->mn.mm); ++ + /* Unregister first so we don't get any more notifications. */ + mmu_notifier_unregister(&handler->mn, handler->mn.mm); + +@@ -143,6 +146,9 @@ void hfi1_mmu_rb_unregister(struct mmu_r + + do_remove(handler, &del_list); + ++ /* Now the mm may be freed. */ ++ mmdrop(handler->mn.mm); ++ + kfree(handler); + } + diff --git a/queue-5.10/series b/queue-5.10/series index a6af9791457..f58490f27f4 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -143,3 +143,9 @@ x86-pm-save-the-msr-validity-status-at-context-setup.patch x86-speculation-restore-speculation-related-msrs-during-s3-resume.patch btrfs-fix-qgroup-reserve-overflow-the-qgroup-limit.patch btrfs-prevent-subvol-with-swapfile-from-being-deleted.patch +arm64-patch_text-fixup-last-cpu-should-be-master.patch +rdma-hfi1-fix-use-after-free-bug-for-mm-struct.patch +gpio-restrict-usage-of-gpio-chip-irq-members-before-initialization.patch +ata-sata_dwc_460ex-fix-crash-due-to-oob-write.patch +perf-qcom_l2_pmu-fix-an-incorrect-null-check-on-list-iterator.patch +irqchip-gic-v3-fix-gicr_ctlr.rwp-polling.patch