From 2cbf8ce143dc73a8447bf44e20b20a9cf4648232 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Sat, 21 May 2022 16:30:45 +0200 Subject: [PATCH] 5.4-stable patches added patches: crypto-qcom-rng-fix-infinite-loop-on-requests-not-multiple-of-word_sz.patch dma-buf-fix-use-of-dma_buf_set_name_-a-b-in-userspace.patch drm-dp-mst-fix-a-possible-memory-leak-in-fetch_monitor_name.patch fix-double-fget-in-vhost_net_set_backend.patch kvm-x86-mmu-update-number-of-zapped-pages-even-if-page-list-is-stable.patch pci-pm-avoid-putting-elo-i2-pcie-ports-in-d3cold.patch perf-fix-sys_perf_event_open-race-against-self.patch --- ...-on-requests-not-multiple-of-word_sz.patch | 40 +++++++++++ ...f-dma_buf_set_name_-a-b-in-userspace.patch | 54 ++++++++++++++ ...le-memory-leak-in-fetch_monitor_name.patch | 32 +++++++++ ...double-fget-in-vhost_net_set_backend.patch | 69 ++++++++++++++++++ ...ed-pages-even-if-page-list-is-stable.patch | 71 +++++++++++++++++++ ...-putting-elo-i2-pcie-ports-in-d3cold.patch | 51 +++++++++++++ ...ys_perf_event_open-race-against-self.patch | 71 +++++++++++++++++++ queue-5.4/series | 7 ++ 8 files changed, 395 insertions(+) create mode 100644 queue-5.4/crypto-qcom-rng-fix-infinite-loop-on-requests-not-multiple-of-word_sz.patch create mode 100644 queue-5.4/dma-buf-fix-use-of-dma_buf_set_name_-a-b-in-userspace.patch create mode 100644 queue-5.4/drm-dp-mst-fix-a-possible-memory-leak-in-fetch_monitor_name.patch create mode 100644 queue-5.4/fix-double-fget-in-vhost_net_set_backend.patch create mode 100644 queue-5.4/kvm-x86-mmu-update-number-of-zapped-pages-even-if-page-list-is-stable.patch create mode 100644 queue-5.4/pci-pm-avoid-putting-elo-i2-pcie-ports-in-d3cold.patch create mode 100644 queue-5.4/perf-fix-sys_perf_event_open-race-against-self.patch diff --git a/queue-5.4/crypto-qcom-rng-fix-infinite-loop-on-requests-not-multiple-of-word_sz.patch b/queue-5.4/crypto-qcom-rng-fix-infinite-loop-on-requests-not-multiple-of-word_sz.patch new file mode 100644 index 00000000000..46a0624dd4e --- /dev/null +++ b/queue-5.4/crypto-qcom-rng-fix-infinite-loop-on-requests-not-multiple-of-word_sz.patch @@ -0,0 +1,40 @@ +From 16287397ec5c08aa58db6acf7dbc55470d78087d Mon Sep 17 00:00:00 2001 +From: Ondrej Mosnacek +Date: Tue, 3 May 2022 13:50:10 +0200 +Subject: crypto: qcom-rng - fix infinite loop on requests not multiple of WORD_SZ + +From: Ondrej Mosnacek + +commit 16287397ec5c08aa58db6acf7dbc55470d78087d upstream. + +The commit referenced in the Fixes tag removed the 'break' from the else +branch in qcom_rng_read(), causing an infinite loop whenever 'max' is +not a multiple of WORD_SZ. This can be reproduced e.g. by running: + + kcapi-rng -b 67 >/dev/null + +There are many ways to fix this without adding back the 'break', but +they all seem more awkward than simply adding it back, so do just that. + +Tested on a machine with Qualcomm Amberwing processor. + +Fixes: a680b1832ced ("crypto: qcom-rng - ensure buffer for generate is completely filled") +Cc: stable@vger.kernel.org +Signed-off-by: Ondrej Mosnacek +Reviewed-by: Brian Masney +Signed-off-by: Herbert Xu +Signed-off-by: Greg Kroah-Hartman +--- + drivers/crypto/qcom-rng.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/crypto/qcom-rng.c ++++ b/drivers/crypto/qcom-rng.c +@@ -64,6 +64,7 @@ static int qcom_rng_read(struct qcom_rng + } else { + /* copy only remaining bytes */ + memcpy(data, &val, max - currsize); ++ break; + } + } while (currsize < max); + diff --git a/queue-5.4/dma-buf-fix-use-of-dma_buf_set_name_-a-b-in-userspace.patch b/queue-5.4/dma-buf-fix-use-of-dma_buf_set_name_-a-b-in-userspace.patch new file mode 100644 index 00000000000..133efc9e573 --- /dev/null +++ b/queue-5.4/dma-buf-fix-use-of-dma_buf_set_name_-a-b-in-userspace.patch @@ -0,0 +1,54 @@ +From 7c3e9fcad9c7d8bb5d69a576044fb16b1d2e8a01 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Pouiller?= +Date: Tue, 17 May 2022 09:27:08 +0200 +Subject: dma-buf: fix use of DMA_BUF_SET_NAME_{A,B} in userspace +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Jérôme Pouiller + +commit 7c3e9fcad9c7d8bb5d69a576044fb16b1d2e8a01 upstream. + +The typedefs u32 and u64 are not available in userspace. Thus user get +an error he try to use DMA_BUF_SET_NAME_A or DMA_BUF_SET_NAME_B: + + $ gcc -Wall -c -MMD -c -o ioctls_list.o ioctls_list.c + In file included from /usr/include/x86_64-linux-gnu/asm/ioctl.h:1, + from /usr/include/linux/ioctl.h:5, + from /usr/include/asm-generic/ioctls.h:5, + from ioctls_list.c:11: + ioctls_list.c:463:29: error: ‘u32’ undeclared here (not in a function) + 463 | { "DMA_BUF_SET_NAME_A", DMA_BUF_SET_NAME_A, -1, -1 }, // linux/dma-buf.h + | ^~~~~~~~~~~~~~~~~~ + ioctls_list.c:464:29: error: ‘u64’ undeclared here (not in a function) + 464 | { "DMA_BUF_SET_NAME_B", DMA_BUF_SET_NAME_B, -1, -1 }, // linux/dma-buf.h + | ^~~~~~~~~~~~~~~~~~ + +The issue was initially reported here[1]. + +[1]: https://github.com/jerome-pouiller/ioctl/pull/14 + +Signed-off-by: Jérôme Pouiller +Reviewed-by: Christian König +Fixes: a5bff92eaac4 ("dma-buf: Fix SET_NAME ioctl uapi") +CC: stable@vger.kernel.org +Link: https://patchwork.freedesktop.org/patch/msgid/20220517072708.245265-1-Jerome.Pouiller@silabs.com +Signed-off-by: Christian König +Signed-off-by: Greg Kroah-Hartman +--- + include/uapi/linux/dma-buf.h | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/include/uapi/linux/dma-buf.h ++++ b/include/uapi/linux/dma-buf.h +@@ -44,7 +44,7 @@ struct dma_buf_sync { + * between them in actual uapi, they're just different numbers. + */ + #define DMA_BUF_SET_NAME _IOW(DMA_BUF_BASE, 1, const char *) +-#define DMA_BUF_SET_NAME_A _IOW(DMA_BUF_BASE, 1, u32) +-#define DMA_BUF_SET_NAME_B _IOW(DMA_BUF_BASE, 1, u64) ++#define DMA_BUF_SET_NAME_A _IOW(DMA_BUF_BASE, 1, __u32) ++#define DMA_BUF_SET_NAME_B _IOW(DMA_BUF_BASE, 1, __u64) + + #endif diff --git a/queue-5.4/drm-dp-mst-fix-a-possible-memory-leak-in-fetch_monitor_name.patch b/queue-5.4/drm-dp-mst-fix-a-possible-memory-leak-in-fetch_monitor_name.patch new file mode 100644 index 00000000000..e9b50c9497e --- /dev/null +++ b/queue-5.4/drm-dp-mst-fix-a-possible-memory-leak-in-fetch_monitor_name.patch @@ -0,0 +1,32 @@ +From 6e03b13cc7d9427c2c77feed1549191015615202 Mon Sep 17 00:00:00 2001 +From: Hangyu Hua +Date: Mon, 16 May 2022 11:20:42 +0800 +Subject: drm/dp/mst: fix a possible memory leak in fetch_monitor_name() + +From: Hangyu Hua + +commit 6e03b13cc7d9427c2c77feed1549191015615202 upstream. + +drm_dp_mst_get_edid call kmemdup to create mst_edid. So mst_edid need to be +freed after use. + +Signed-off-by: Hangyu Hua +Reviewed-by: Lyude Paul +Signed-off-by: Lyude Paul +Cc: stable@vger.kernel.org +Link: https://patchwork.freedesktop.org/patch/msgid/20220516032042.13166-1-hbh25y@gmail.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/drm_dp_mst_topology.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/gpu/drm/drm_dp_mst_topology.c ++++ b/drivers/gpu/drm/drm_dp_mst_topology.c +@@ -3657,6 +3657,7 @@ static void fetch_monitor_name(struct dr + + mst_edid = drm_dp_mst_get_edid(port->connector, mgr, port); + drm_edid_get_monitor_name(mst_edid, name, namelen); ++ kfree(mst_edid); + } + + /** diff --git a/queue-5.4/fix-double-fget-in-vhost_net_set_backend.patch b/queue-5.4/fix-double-fget-in-vhost_net_set_backend.patch new file mode 100644 index 00000000000..3a3b7e8c84c --- /dev/null +++ b/queue-5.4/fix-double-fget-in-vhost_net_set_backend.patch @@ -0,0 +1,69 @@ +From fb4554c2232e44d595920f4d5c66cf8f7d13f9bc Mon Sep 17 00:00:00 2001 +From: Al Viro +Date: Mon, 16 May 2022 16:42:13 +0800 +Subject: Fix double fget() in vhost_net_set_backend() + +From: Al Viro + +commit fb4554c2232e44d595920f4d5c66cf8f7d13f9bc upstream. + +Descriptor table is a shared resource; two fget() on the same descriptor +may return different struct file references. get_tap_ptr_ring() is +called after we'd found (and pinned) the socket we'll be using and it +tries to find the private tun/tap data structures associated with it. +Redoing the lookup by the same file descriptor we'd used to get the +socket is racy - we need to same struct file. + +Thanks to Jason for spotting a braino in the original variant of patch - +I'd missed the use of fd == -1 for disabling backend, and in that case +we can end up with sock == NULL and sock != oldsock. + +Cc: stable@kernel.org +Acked-by: Michael S. Tsirkin +Signed-off-by: Jason Wang +Signed-off-by: Al Viro +Signed-off-by: Greg Kroah-Hartman +--- + drivers/vhost/net.c | 15 +++++++-------- + 1 file changed, 7 insertions(+), 8 deletions(-) + +--- a/drivers/vhost/net.c ++++ b/drivers/vhost/net.c +@@ -1446,13 +1446,9 @@ err: + return ERR_PTR(r); + } + +-static struct ptr_ring *get_tap_ptr_ring(int fd) ++static struct ptr_ring *get_tap_ptr_ring(struct file *file) + { + struct ptr_ring *ring; +- struct file *file = fget(fd); +- +- if (!file) +- return NULL; + ring = tun_get_tx_ring(file); + if (!IS_ERR(ring)) + goto out; +@@ -1461,7 +1457,6 @@ static struct ptr_ring *get_tap_ptr_ring + goto out; + ring = NULL; + out: +- fput(file); + return ring; + } + +@@ -1548,8 +1543,12 @@ static long vhost_net_set_backend(struct + r = vhost_net_enable_vq(n, vq); + if (r) + goto err_used; +- if (index == VHOST_NET_VQ_RX) +- nvq->rx_ring = get_tap_ptr_ring(fd); ++ if (index == VHOST_NET_VQ_RX) { ++ if (sock) ++ nvq->rx_ring = get_tap_ptr_ring(sock->file); ++ else ++ nvq->rx_ring = NULL; ++ } + + oldubufs = nvq->ubufs; + nvq->ubufs = ubufs; diff --git a/queue-5.4/kvm-x86-mmu-update-number-of-zapped-pages-even-if-page-list-is-stable.patch b/queue-5.4/kvm-x86-mmu-update-number-of-zapped-pages-even-if-page-list-is-stable.patch new file mode 100644 index 00000000000..eca125a176b --- /dev/null +++ b/queue-5.4/kvm-x86-mmu-update-number-of-zapped-pages-even-if-page-list-is-stable.patch @@ -0,0 +1,71 @@ +From b28cb0cd2c5e80a8c0feb408a0e4b0dbb6d132c5 Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Wed, 11 May 2022 14:51:22 +0000 +Subject: KVM: x86/mmu: Update number of zapped pages even if page list is stable + +From: Sean Christopherson + +commit b28cb0cd2c5e80a8c0feb408a0e4b0dbb6d132c5 upstream. + +When zapping obsolete pages, update the running count of zapped pages +regardless of whether or not the list has become unstable due to zapping +a shadow page with its own child shadow pages. If the VM is backed by +mostly 4kb pages, KVM can zap an absurd number of SPTEs without bumping +the batch count and thus without yielding. In the worst case scenario, +this can cause a soft lokcup. + + watchdog: BUG: soft lockup - CPU#12 stuck for 22s! [dirty_log_perf_:13020] + RIP: 0010:workingset_activation+0x19/0x130 + mark_page_accessed+0x266/0x2e0 + kvm_set_pfn_accessed+0x31/0x40 + mmu_spte_clear_track_bits+0x136/0x1c0 + drop_spte+0x1a/0xc0 + mmu_page_zap_pte+0xef/0x120 + __kvm_mmu_prepare_zap_page+0x205/0x5e0 + kvm_mmu_zap_all_fast+0xd7/0x190 + kvm_mmu_invalidate_zap_pages_in_memslot+0xe/0x10 + kvm_page_track_flush_slot+0x5c/0x80 + kvm_arch_flush_shadow_memslot+0xe/0x10 + kvm_set_memslot+0x1a8/0x5d0 + __kvm_set_memory_region+0x337/0x590 + kvm_vm_ioctl+0xb08/0x1040 + +Fixes: fbb158cb88b6 ("KVM: x86/mmu: Revert "Revert "KVM: MMU: zap pages in batch""") +Reported-by: David Matlack +Reviewed-by: Ben Gardon +Cc: stable@vger.kernel.org +Signed-off-by: Sean Christopherson +Message-Id: <20220511145122.3133334-1-seanjc@google.com> +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/mmu.c | 10 ++++++---- + 1 file changed, 6 insertions(+), 4 deletions(-) + +--- a/arch/x86/kvm/mmu.c ++++ b/arch/x86/kvm/mmu.c +@@ -5821,6 +5821,7 @@ static void kvm_zap_obsolete_pages(struc + { + struct kvm_mmu_page *sp, *node; + int nr_zapped, batch = 0; ++ bool unstable; + + restart: + list_for_each_entry_safe_reverse(sp, node, +@@ -5853,11 +5854,12 @@ restart: + goto restart; + } + +- if (__kvm_mmu_prepare_zap_page(kvm, sp, +- &kvm->arch.zapped_obsolete_pages, &nr_zapped)) { +- batch += nr_zapped; ++ unstable = __kvm_mmu_prepare_zap_page(kvm, sp, ++ &kvm->arch.zapped_obsolete_pages, &nr_zapped); ++ batch += nr_zapped; ++ ++ if (unstable) + goto restart; +- } + } + + /* diff --git a/queue-5.4/pci-pm-avoid-putting-elo-i2-pcie-ports-in-d3cold.patch b/queue-5.4/pci-pm-avoid-putting-elo-i2-pcie-ports-in-d3cold.patch new file mode 100644 index 00000000000..d7ebc1a7b2b --- /dev/null +++ b/queue-5.4/pci-pm-avoid-putting-elo-i2-pcie-ports-in-d3cold.patch @@ -0,0 +1,51 @@ +From 92597f97a40bf661bebceb92e26ff87c76d562d4 Mon Sep 17 00:00:00 2001 +From: "Rafael J. Wysocki" +Date: Thu, 31 Mar 2022 19:38:51 +0200 +Subject: PCI/PM: Avoid putting Elo i2 PCIe Ports in D3cold + +From: Rafael J. Wysocki + +commit 92597f97a40bf661bebceb92e26ff87c76d562d4 upstream. + +If a Root Port on Elo i2 is put into D3cold and then back into D0, the +downstream device becomes permanently inaccessible, so add a bridge D3 DMI +quirk for that system. + +This was exposed by 14858dcc3b35 ("PCI: Use pci_update_current_state() in +pci_enable_device_flags()"), but before that commit the Root Port in +question had never been put into D3cold for real due to a mismatch between +its power state retrieved from the PCI_PM_CTRL register (which was +accessible even though the platform firmware indicated that the port was in +D3cold) and the state of an ACPI power resource involved in its power +management. + +BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=215715 +Link: https://lore.kernel.org/r/11980172.O9o76ZdvQC@kreacher +Reported-by: Stefan Gottwald +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Bjorn Helgaas +Cc: stable@vger.kernel.org # v5.15+ +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/pci.c | 10 ++++++++++ + 1 file changed, 10 insertions(+) + +--- a/drivers/pci/pci.c ++++ b/drivers/pci/pci.c +@@ -2613,6 +2613,16 @@ static const struct dmi_system_id bridge + DMI_MATCH(DMI_BOARD_VENDOR, "Gigabyte Technology Co., Ltd."), + DMI_MATCH(DMI_BOARD_NAME, "X299 DESIGNARE EX-CF"), + }, ++ /* ++ * Downstream device is not accessible after putting a root port ++ * into D3cold and back into D0 on Elo i2. ++ */ ++ .ident = "Elo i2", ++ .matches = { ++ DMI_MATCH(DMI_SYS_VENDOR, "Elo Touch Solutions"), ++ DMI_MATCH(DMI_PRODUCT_NAME, "Elo i2"), ++ DMI_MATCH(DMI_PRODUCT_VERSION, "RevB"), ++ }, + }, + #endif + { } diff --git a/queue-5.4/perf-fix-sys_perf_event_open-race-against-self.patch b/queue-5.4/perf-fix-sys_perf_event_open-race-against-self.patch new file mode 100644 index 00000000000..973029e0d62 --- /dev/null +++ b/queue-5.4/perf-fix-sys_perf_event_open-race-against-self.patch @@ -0,0 +1,71 @@ +From 3ac6487e584a1eb54071dbe1212e05b884136704 Mon Sep 17 00:00:00 2001 +From: Peter Zijlstra +Date: Fri, 20 May 2022 20:38:06 +0200 +Subject: perf: Fix sys_perf_event_open() race against self + +From: Peter Zijlstra + +commit 3ac6487e584a1eb54071dbe1212e05b884136704 upstream. + +Norbert reported that it's possible to race sys_perf_event_open() such +that the looser ends up in another context from the group leader, +triggering many WARNs. + +The move_group case checks for races against itself, but the +!move_group case doesn't, seemingly relying on the previous +group_leader->ctx == ctx check. However, that check is racy due to not +holding any locks at that time. + +Therefore, re-check the result after acquiring locks and bailing +if they no longer match. + +Additionally, clarify the not_move_group case from the +move_group-vs-move_group race. + +Fixes: f63a8daa5812 ("perf: Fix event->ctx locking") +Reported-by: Norbert Slusarek +Signed-off-by: Peter Zijlstra (Intel) +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman +--- + kernel/events/core.c | 14 ++++++++++++++ + 1 file changed, 14 insertions(+) + +--- a/kernel/events/core.c ++++ b/kernel/events/core.c +@@ -11114,6 +11114,9 @@ SYSCALL_DEFINE5(perf_event_open, + * Do not allow to attach to a group in a different task + * or CPU context. If we're moving SW events, we'll fix + * this up later, so allow that. ++ * ++ * Racy, not holding group_leader->ctx->mutex, see comment with ++ * perf_event_ctx_lock(). + */ + if (!move_group && group_leader->ctx != ctx) + goto err_context; +@@ -11181,6 +11184,7 @@ SYSCALL_DEFINE5(perf_event_open, + } else { + perf_event_ctx_unlock(group_leader, gctx); + move_group = 0; ++ goto not_move_group; + } + } + +@@ -11197,7 +11201,17 @@ SYSCALL_DEFINE5(perf_event_open, + } + } else { + mutex_lock(&ctx->mutex); ++ ++ /* ++ * Now that we hold ctx->lock, (re)validate group_leader->ctx == ctx, ++ * see the group_leader && !move_group test earlier. ++ */ ++ if (group_leader && group_leader->ctx != ctx) { ++ err = -EINVAL; ++ goto err_locked; ++ } + } ++not_move_group: + + if (ctx->task == TASK_TOMBSTONE) { + err = -ESRCH; diff --git a/queue-5.4/series b/queue-5.4/series index 825aaf93695..64dbde6b7fa 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -24,3 +24,10 @@ sunrpc-prevent-immediate-close-reconnect.patch sunrpc-don-t-call-connect-more-than-once-on-a-tcp-socket.patch sunrpc-ensure-we-flush-any-closed-sockets-before-xs_xprt_free.patch alsa-wavefront-proper-check-of-get_user-error.patch +perf-fix-sys_perf_event_open-race-against-self.patch +fix-double-fget-in-vhost_net_set_backend.patch +pci-pm-avoid-putting-elo-i2-pcie-ports-in-d3cold.patch +kvm-x86-mmu-update-number-of-zapped-pages-even-if-page-list-is-stable.patch +crypto-qcom-rng-fix-infinite-loop-on-requests-not-multiple-of-word_sz.patch +drm-dp-mst-fix-a-possible-memory-leak-in-fetch_monitor_name.patch +dma-buf-fix-use-of-dma_buf_set_name_-a-b-in-userspace.patch -- 2.47.3