--- /dev/null
+From 16287397ec5c08aa58db6acf7dbc55470d78087d Mon Sep 17 00:00:00 2001
+From: Ondrej Mosnacek <omosnace@redhat.com>
+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 <omosnace@redhat.com>
+
+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 <omosnace@redhat.com>
+Reviewed-by: Brian Masney <bmasney@redhat.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
+
--- /dev/null
+From 7c3e9fcad9c7d8bb5d69a576044fb16b1d2e8a01 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Pouiller?= <jerome.pouiller@silabs.com>
+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 <jerome.pouiller@silabs.com>
+
+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 <jerome.pouiller@silabs.com>
+Reviewed-by: Christian König <christian.koenig@amd.com>
+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 <christian.koenig@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
--- /dev/null
+From 6e03b13cc7d9427c2c77feed1549191015615202 Mon Sep 17 00:00:00 2001
+From: Hangyu Hua <hbh25y@gmail.com>
+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 <hbh25y@gmail.com>
+
+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 <hbh25y@gmail.com>
+Reviewed-by: Lyude Paul <lyude@redhat.com>
+Signed-off-by: Lyude Paul <lyude@redhat.com>
+Cc: stable@vger.kernel.org
+Link: https://patchwork.freedesktop.org/patch/msgid/20220516032042.13166-1-hbh25y@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
+ }
+
+ /**
--- /dev/null
+From fb4554c2232e44d595920f4d5c66cf8f7d13f9bc Mon Sep 17 00:00:00 2001
+From: Al Viro <viro@zeniv.linux.org.uk>
+Date: Mon, 16 May 2022 16:42:13 +0800
+Subject: Fix double fget() in vhost_net_set_backend()
+
+From: Al Viro <viro@zeniv.linux.org.uk>
+
+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 <mst@redhat.com>
+Signed-off-by: Jason Wang <jasowang@redhat.com>
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From b28cb0cd2c5e80a8c0feb408a0e4b0dbb6d132c5 Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+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 <seanjc@google.com>
+
+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 <dmatlack@google.com>
+Reviewed-by: Ben Gardon <bgardon@google.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Message-Id: <20220511145122.3133334-1-seanjc@google.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+- }
+ }
+
+ /*
--- /dev/null
+From 92597f97a40bf661bebceb92e26ff87c76d562d4 Mon Sep 17 00:00:00 2001
+From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
+Date: Thu, 31 Mar 2022 19:38:51 +0200
+Subject: PCI/PM: Avoid putting Elo i2 PCIe Ports in D3cold
+
+From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+
+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 <gottwald@igel.com>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Cc: stable@vger.kernel.org # v5.15+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+ { }
--- /dev/null
+From 3ac6487e584a1eb54071dbe1212e05b884136704 Mon Sep 17 00:00:00 2001
+From: Peter Zijlstra <peterz@infradead.org>
+Date: Fri, 20 May 2022 20:38:06 +0200
+Subject: perf: Fix sys_perf_event_open() race against self
+
+From: Peter Zijlstra <peterz@infradead.org>
+
+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 <nslusarek@gmx.net>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
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
projects / thirdparty / kernel / stable-queue.git / commitdiff
