--- /dev/null
+From d942856865c733ff60450de9691af796ad71d7bc Mon Sep 17 00:00:00 2001
+From: Charlene Liu <Charlene.Liu@amd.com>
+Date: Mon, 20 Sep 2021 14:30:02 -0400
+Subject: drm/amd/display: Pass PCI deviceid into DC
+
+From: Charlene Liu <Charlene.Liu@amd.com>
+
+commit d942856865c733ff60450de9691af796ad71d7bc upstream.
+
+[why]
+pci deviceid not passed to dal dc, without proper break,
+dcn2.x falls into dcn3.x code path
+
+[how]
+pass in pci deviceid, and break once dal_version initialized.
+
+Reviewed-by: Zhan Liu <Zhan.Liu@amd.com>
+Acked-by: Anson Jacob <Anson.Jacob@amd.com>
+Signed-off-by: Charlene Liu <Charlene.Liu@amd.com>
+Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
++++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+@@ -951,6 +951,7 @@ static int amdgpu_dm_init(struct amdgpu_
+
+ init_data.asic_id.pci_revision_id = adev->pdev->revision;
+ init_data.asic_id.hw_internal_rev = adev->external_rev_id;
++ init_data.asic_id.chip_id = adev->pdev->device;
+
+ init_data.asic_id.vram_width = adev->gmc.vram_width;
+ /* TODO: initialize init_data.asic_id.vram_type here!!!! */
--- /dev/null
+From 9f52c25f59b504a29dda42d83ac1e24d2af535d4 Mon Sep 17 00:00:00 2001
+From: Hawking Zhang <Hawking.Zhang@amd.com>
+Date: Sun, 26 Sep 2021 22:19:35 +0800
+Subject: drm/amdgpu: correct initial cp_hqd_quantum for gfx9
+
+From: Hawking Zhang <Hawking.Zhang@amd.com>
+
+commit 9f52c25f59b504a29dda42d83ac1e24d2af535d4 upstream.
+
+didn't read the value of mmCP_HQD_QUANTUM from correct
+register offset
+
+Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
+Reviewed-by: Le Ma <Le.Ma@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
++++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+@@ -3542,7 +3542,7 @@ static int gfx_v9_0_mqd_init(struct amdg
+
+ /* set static priority for a queue/ring */
+ gfx_v9_0_mqd_set_priority(ring, mqd);
+- mqd->cp_hqd_quantum = RREG32(mmCP_HQD_QUANTUM);
++ mqd->cp_hqd_quantum = RREG32_SOC15(GC, 0, mmCP_HQD_QUANTUM);
+
+ /* map_queues packet doesn't need activate the queue,
+ * so only kiq need set this field.
--- /dev/null
+From 8d68bad6d869fae8f4d50ab6423538dec7da72d1 Mon Sep 17 00:00:00 2001
+From: Vitaly Kuznetsov <vkuznets@redhat.com>
+Date: Tue, 7 Sep 2021 18:35:30 +0200
+Subject: KVM: nVMX: Filter out all unsupported controls when eVMCS was activated
+
+From: Vitaly Kuznetsov <vkuznets@redhat.com>
+
+commit 8d68bad6d869fae8f4d50ab6423538dec7da72d1 upstream.
+
+Windows Server 2022 with Hyper-V role enabled failed to boot on KVM when
+enlightened VMCS is advertised. Debugging revealed there are two exposed
+secondary controls it is not happy with: SECONDARY_EXEC_ENABLE_VMFUNC and
+SECONDARY_EXEC_SHADOW_VMCS. These controls are known to be unsupported,
+as there are no corresponding fields in eVMCSv1 (see the comment above
+EVMCS1_UNSUPPORTED_2NDEXEC definition).
+
+Previously, commit 31de3d2500e4 ("x86/kvm/hyper-v: move VMX controls
+sanitization out of nested_enable_evmcs()") introduced the required
+filtering mechanism for VMX MSRs but for some reason put only known
+to be problematic (and not full EVMCS1_UNSUPPORTED_* lists) controls
+there.
+
+Note, Windows Server 2022 seems to have gained some sanity check for VMX
+MSRs: it doesn't even try to launch a guest when there's something it
+doesn't like, nested_evmcs_check_controls() mechanism can't catch the
+problem.
+
+Let's be bold this time and instead of playing whack-a-mole just filter out
+all unsupported controls from VMX MSRs.
+
+Fixes: 31de3d2500e4 ("x86/kvm/hyper-v: move VMX controls sanitization out of nested_enable_evmcs()")
+Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
+Message-Id: <20210907163530.110066-1-vkuznets@redhat.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/vmx/evmcs.c | 12 +++++++++---
+ arch/x86/kvm/vmx/vmx.c | 9 +++++----
+ 2 files changed, 14 insertions(+), 7 deletions(-)
+
+--- a/arch/x86/kvm/vmx/evmcs.c
++++ b/arch/x86/kvm/vmx/evmcs.c
+@@ -352,14 +352,20 @@ void nested_evmcs_filter_control_msr(u32
+ switch (msr_index) {
+ case MSR_IA32_VMX_EXIT_CTLS:
+ case MSR_IA32_VMX_TRUE_EXIT_CTLS:
+- ctl_high &= ~VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL;
++ ctl_high &= ~EVMCS1_UNSUPPORTED_VMEXIT_CTRL;
+ break;
+ case MSR_IA32_VMX_ENTRY_CTLS:
+ case MSR_IA32_VMX_TRUE_ENTRY_CTLS:
+- ctl_high &= ~VM_ENTRY_LOAD_IA32_PERF_GLOBAL_CTRL;
++ ctl_high &= ~EVMCS1_UNSUPPORTED_VMENTRY_CTRL;
+ break;
+ case MSR_IA32_VMX_PROCBASED_CTLS2:
+- ctl_high &= ~SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES;
++ ctl_high &= ~EVMCS1_UNSUPPORTED_2NDEXEC;
++ break;
++ case MSR_IA32_VMX_PINBASED_CTLS:
++ ctl_high &= ~EVMCS1_UNSUPPORTED_PINCTRL;
++ break;
++ case MSR_IA32_VMX_VMFUNC:
++ ctl_low &= ~EVMCS1_UNSUPPORTED_VMFUNC;
+ break;
+ }
+
+--- a/arch/x86/kvm/vmx/vmx.c
++++ b/arch/x86/kvm/vmx/vmx.c
+@@ -1867,10 +1867,11 @@ static int vmx_get_msr(struct kvm_vcpu *
+ &msr_info->data))
+ return 1;
+ /*
+- * Enlightened VMCS v1 doesn't have certain fields, but buggy
+- * Hyper-V versions are still trying to use corresponding
+- * features when they are exposed. Filter out the essential
+- * minimum.
++ * Enlightened VMCS v1 doesn't have certain VMCS fields but
++ * instead of just ignoring the features, different Hyper-V
++ * versions are either trying to use them and fail or do some
++ * sanity checking and refuse to boot. Filter all unsupported
++ * features out.
+ */
+ if (!msr_info->host_initiated &&
+ vmx->nested.enlightened_vmcs_enabled)
--- /dev/null
+From 8646e53633f314e4d746a988240d3b951a92f94a Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+Date: Wed, 1 Sep 2021 13:30:26 -0700
+Subject: KVM: rseq: Update rseq when processing NOTIFY_RESUME on xfer to KVM guest
+
+From: Sean Christopherson <seanjc@google.com>
+
+commit 8646e53633f314e4d746a988240d3b951a92f94a upstream.
+
+Invoke rseq's NOTIFY_RESUME handler when processing the flag prior to
+transferring to a KVM guest, which is roughly equivalent to an exit to
+userspace and processes many of the same pending actions. While the task
+cannot be in an rseq critical section as the KVM path is reachable only
+by via ioctl(KVM_RUN), the side effects that apply to rseq outside of a
+critical section still apply, e.g. the current CPU needs to be updated if
+the task is migrated.
+
+Clearing TIF_NOTIFY_RESUME without informing rseq can lead to segfaults
+and other badness in userspace VMMs that use rseq in combination with KVM,
+e.g. due to the CPU ID being stale after task migration.
+
+Fixes: 72c3c0fe54a3 ("x86/kvm: Use generic xfer to guest work function")
+Reported-by: Peter Foley <pefoley@google.com>
+Bisected-by: Doug Evans <dje@google.com>
+Acked-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
+Cc: Shakeel Butt <shakeelb@google.com>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: stable@vger.kernel.org
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Message-Id: <20210901203030.1292304-2-seanjc@google.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+[sean: Resolve benign conflict due to unrelated access_ok() check in 5.10]
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/entry/kvm.c | 4 +++-
+ kernel/rseq.c | 13 ++++++++++---
+ 2 files changed, 13 insertions(+), 4 deletions(-)
+
+--- a/kernel/entry/kvm.c
++++ b/kernel/entry/kvm.c
+@@ -16,8 +16,10 @@ static int xfer_to_guest_mode_work(struc
+ if (ti_work & _TIF_NEED_RESCHED)
+ schedule();
+
+- if (ti_work & _TIF_NOTIFY_RESUME)
++ if (ti_work & _TIF_NOTIFY_RESUME) {
+ tracehook_notify_resume(NULL);
++ rseq_handle_notify_resume(NULL, NULL);
++ }
+
+ ret = arch_xfer_to_guest_mode_handle_work(vcpu, ti_work);
+ if (ret)
+--- a/kernel/rseq.c
++++ b/kernel/rseq.c
+@@ -268,9 +268,16 @@ void __rseq_handle_notify_resume(struct
+ return;
+ if (unlikely(!access_ok(t->rseq, sizeof(*t->rseq))))
+ goto error;
+- ret = rseq_ip_fixup(regs);
+- if (unlikely(ret < 0))
+- goto error;
++ /*
++ * regs is NULL if and only if the caller is in a syscall path. Skip
++ * fixup and leave rseq_cs as is so that rseq_sycall() will detect and
++ * kill a misbehaving userspace on debug kernels.
++ */
++ if (regs) {
++ ret = rseq_ip_fixup(regs);
++ if (unlikely(ret < 0))
++ goto error;
++ }
+ if (unlikely(rseq_update_cpu_id(t)))
+ goto error;
+ return;
--- /dev/null
+From 2f9b68f57c6278c322793a06063181deded0ad69 Mon Sep 17 00:00:00 2001
+From: Vitaly Kuznetsov <vkuznets@redhat.com>
+Date: Fri, 27 Aug 2021 11:25:14 +0200
+Subject: KVM: x86: Fix stack-out-of-bounds memory access from ioapic_write_indirect()
+
+From: Vitaly Kuznetsov <vkuznets@redhat.com>
+
+commit 2f9b68f57c6278c322793a06063181deded0ad69 upstream.
+
+KASAN reports the following issue:
+
+ BUG: KASAN: stack-out-of-bounds in kvm_make_vcpus_request_mask+0x174/0x440 [kvm]
+ Read of size 8 at addr ffffc9001364f638 by task qemu-kvm/4798
+
+ CPU: 0 PID: 4798 Comm: qemu-kvm Tainted: G X --------- ---
+ Hardware name: AMD Corporation DAYTONA_X/DAYTONA_X, BIOS RYM0081C 07/13/2020
+ Call Trace:
+ dump_stack+0xa5/0xe6
+ print_address_description.constprop.0+0x18/0x130
+ ? kvm_make_vcpus_request_mask+0x174/0x440 [kvm]
+ __kasan_report.cold+0x7f/0x114
+ ? kvm_make_vcpus_request_mask+0x174/0x440 [kvm]
+ kasan_report+0x38/0x50
+ kasan_check_range+0xf5/0x1d0
+ kvm_make_vcpus_request_mask+0x174/0x440 [kvm]
+ kvm_make_scan_ioapic_request_mask+0x84/0xc0 [kvm]
+ ? kvm_arch_exit+0x110/0x110 [kvm]
+ ? sched_clock+0x5/0x10
+ ioapic_write_indirect+0x59f/0x9e0 [kvm]
+ ? static_obj+0xc0/0xc0
+ ? __lock_acquired+0x1d2/0x8c0
+ ? kvm_ioapic_eoi_inject_work+0x120/0x120 [kvm]
+
+The problem appears to be that 'vcpu_bitmap' is allocated as a single long
+on stack and it should really be KVM_MAX_VCPUS long. We also seem to clear
+the lower 16 bits of it with bitmap_zero() for no particular reason (my
+guess would be that 'bitmap' and 'vcpu_bitmap' variables in
+kvm_bitmap_or_dest_vcpus() caused the confusion: while the later is indeed
+16-bit long, the later should accommodate all possible vCPUs).
+
+Fixes: 7ee30bc132c6 ("KVM: x86: deliver KVM IOAPIC scan request to target vCPUs")
+Fixes: 9a2ae9f6b6bb ("KVM: x86: Zero the IOAPIC scan request dest vCPUs bitmap")
+Reported-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
+Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
+Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
+Reviewed-by: Sean Christopherson <seanjc@google.com>
+Message-Id: <20210827092516.1027264-7-vkuznets@redhat.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/ioapic.c | 10 +++++-----
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+--- a/arch/x86/kvm/ioapic.c
++++ b/arch/x86/kvm/ioapic.c
+@@ -319,8 +319,8 @@ static void ioapic_write_indirect(struct
+ unsigned index;
+ bool mask_before, mask_after;
+ union kvm_ioapic_redirect_entry *e;
+- unsigned long vcpu_bitmap;
+ int old_remote_irr, old_delivery_status, old_dest_id, old_dest_mode;
++ DECLARE_BITMAP(vcpu_bitmap, KVM_MAX_VCPUS);
+
+ switch (ioapic->ioregsel) {
+ case IOAPIC_REG_VERSION:
+@@ -384,9 +384,9 @@ static void ioapic_write_indirect(struct
+ irq.shorthand = APIC_DEST_NOSHORT;
+ irq.dest_id = e->fields.dest_id;
+ irq.msi_redir_hint = false;
+- bitmap_zero(&vcpu_bitmap, 16);
++ bitmap_zero(vcpu_bitmap, KVM_MAX_VCPUS);
+ kvm_bitmap_or_dest_vcpus(ioapic->kvm, &irq,
+- &vcpu_bitmap);
++ vcpu_bitmap);
+ if (old_dest_mode != e->fields.dest_mode ||
+ old_dest_id != e->fields.dest_id) {
+ /*
+@@ -399,10 +399,10 @@ static void ioapic_write_indirect(struct
+ kvm_lapic_irq_dest_mode(
+ !!e->fields.dest_mode);
+ kvm_bitmap_or_dest_vcpus(ioapic->kvm, &irq,
+- &vcpu_bitmap);
++ vcpu_bitmap);
+ }
+ kvm_make_scan_ioapic_request_mask(ioapic->kvm,
+- &vcpu_bitmap);
++ vcpu_bitmap);
+ } else {
+ kvm_make_scan_ioapic_request(ioapic->kvm);
+ }
--- /dev/null
+From faf6b755629627f19feafa75b32e81cd7738f12d Mon Sep 17 00:00:00 2001
+From: Maxim Levitsky <mlevitsk@redhat.com>
+Date: Tue, 14 Sep 2021 18:48:16 +0300
+Subject: KVM: x86: nSVM: don't copy virt_ext from vmcb12
+
+From: Maxim Levitsky <mlevitsk@redhat.com>
+
+commit faf6b755629627f19feafa75b32e81cd7738f12d upstream.
+
+These field correspond to features that we don't expose yet to L2
+
+While currently there are no CVE worthy features in this field,
+if AMD adds more features to this field, that could allow guest
+escapes similar to CVE-2021-3653 and CVE-2021-3656.
+
+Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
+Message-Id: <20210914154825.104886-6-mlevitsk@redhat.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/svm/nested.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/arch/x86/kvm/svm/nested.c
++++ b/arch/x86/kvm/svm/nested.c
+@@ -447,7 +447,6 @@ static void nested_prepare_vmcb_control(
+ (svm->nested.ctl.int_ctl & int_ctl_vmcb12_bits) |
+ (svm->nested.hsave->control.int_ctl & int_ctl_vmcb01_bits);
+
+- svm->vmcb->control.virt_ext = svm->nested.ctl.virt_ext;
+ svm->vmcb->control.int_vector = svm->nested.ctl.int_vector;
+ svm->vmcb->control.int_state = svm->nested.ctl.int_state;
+ svm->vmcb->control.event_inj = svm->nested.ctl.event_inj;
--- /dev/null
+From f0c15b360fb65ee39849afe987c16eb3d0175d0d Mon Sep 17 00:00:00 2001
+From: Sean Young <sean@mess.org>
+Date: Tue, 14 Sep 2021 16:57:46 +0200
+Subject: media: ir_toy: prevent device from hanging during transmit
+
+From: Sean Young <sean@mess.org>
+
+commit f0c15b360fb65ee39849afe987c16eb3d0175d0d upstream.
+
+If the IR Toy is receiving IR while a transmit is done, it may end up
+hanging. We can prevent this from happening by re-entering sample mode
+just before issuing the transmit command.
+
+Link: https://github.com/bengtmartensson/HarcHardware/discussions/25
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Sean Young <sean@mess.org>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/rc/ir_toy.c | 21 ++++++++++++++++++++-
+ 1 file changed, 20 insertions(+), 1 deletion(-)
+
+--- a/drivers/media/rc/ir_toy.c
++++ b/drivers/media/rc/ir_toy.c
+@@ -24,6 +24,7 @@ static const u8 COMMAND_VERSION[] = { 'v
+ // End transmit and repeat reset command so we exit sump mode
+ static const u8 COMMAND_RESET[] = { 0xff, 0xff, 0, 0, 0, 0, 0 };
+ static const u8 COMMAND_SMODE_ENTER[] = { 's' };
++static const u8 COMMAND_SMODE_EXIT[] = { 0 };
+ static const u8 COMMAND_TXSTART[] = { 0x26, 0x24, 0x25, 0x03 };
+
+ #define REPLY_XMITCOUNT 't'
+@@ -309,12 +310,30 @@ static int irtoy_tx(struct rc_dev *rc, u
+ buf[i] = cpu_to_be16(v);
+ }
+
+- buf[count] = cpu_to_be16(0xffff);
++ buf[count] = 0xffff;
+
+ irtoy->tx_buf = buf;
+ irtoy->tx_len = size;
+ irtoy->emitted = 0;
+
++ // There is an issue where if the unit is receiving IR while the
++ // first TXSTART command is sent, the device might end up hanging
++ // with its led on. It does not respond to any command when this
++ // happens. To work around this, re-enter sample mode.
++ err = irtoy_command(irtoy, COMMAND_SMODE_EXIT,
++ sizeof(COMMAND_SMODE_EXIT), STATE_RESET);
++ if (err) {
++ dev_err(irtoy->dev, "exit sample mode: %d\n", err);
++ return err;
++ }
++
++ err = irtoy_command(irtoy, COMMAND_SMODE_ENTER,
++ sizeof(COMMAND_SMODE_ENTER), STATE_COMMAND);
++ if (err) {
++ dev_err(irtoy->dev, "enter sample mode: %d\n", err);
++ return err;
++ }
++
+ err = irtoy_command(irtoy, COMMAND_TXSTART, sizeof(COMMAND_TXSTART),
+ STATE_TX);
+ kfree(buf);
--- /dev/null
+From bc0bdc5afaa740d782fbf936aaeebd65e5c2921d Mon Sep 17 00:00:00 2001
+From: Jason Gunthorpe <jgg@nvidia.com>
+Date: Wed, 15 Sep 2021 17:21:43 -0300
+Subject: RDMA/cma: Do not change route.addr.src_addr.ss_family
+
+From: Jason Gunthorpe <jgg@nvidia.com>
+
+commit bc0bdc5afaa740d782fbf936aaeebd65e5c2921d upstream.
+
+If the state is not idle then rdma_bind_addr() will immediately fail and
+no change to global state should happen.
+
+For instance if the state is already RDMA_CM_LISTEN then this will corrupt
+the src_addr and would cause the test in cma_cancel_operation():
+
+ if (cma_any_addr(cma_src_addr(id_priv)) && !id_priv->cma_dev)
+
+To view a mangled src_addr, eg with a IPv6 loopback address but an IPv4
+family, failing the test.
+
+This would manifest as this trace from syzkaller:
+
+ BUG: KASAN: use-after-free in __list_add_valid+0x93/0xa0 lib/list_debug.c:26
+ Read of size 8 at addr ffff8881546491e0 by task syz-executor.1/32204
+
+ CPU: 1 PID: 32204 Comm: syz-executor.1 Not tainted 5.12.0-rc8-syzkaller #0
+ Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
+ Call Trace:
+ __dump_stack lib/dump_stack.c:79 [inline]
+ dump_stack+0x141/0x1d7 lib/dump_stack.c:120
+ print_address_description.constprop.0.cold+0x5b/0x2f8 mm/kasan/report.c:232
+ __kasan_report mm/kasan/report.c:399 [inline]
+ kasan_report.cold+0x7c/0xd8 mm/kasan/report.c:416
+ __list_add_valid+0x93/0xa0 lib/list_debug.c:26
+ __list_add include/linux/list.h:67 [inline]
+ list_add_tail include/linux/list.h:100 [inline]
+ cma_listen_on_all drivers/infiniband/core/cma.c:2557 [inline]
+ rdma_listen+0x787/0xe00 drivers/infiniband/core/cma.c:3751
+ ucma_listen+0x16a/0x210 drivers/infiniband/core/ucma.c:1102
+ ucma_write+0x259/0x350 drivers/infiniband/core/ucma.c:1732
+ vfs_write+0x28e/0xa30 fs/read_write.c:603
+ ksys_write+0x1ee/0x250 fs/read_write.c:658
+ do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
+ entry_SYSCALL_64_after_hwframe+0x44/0xae
+
+Which is indicating that an rdma_id_private was destroyed without doing
+cma_cancel_listens().
+
+Instead of trying to re-use the src_addr memory to indirectly create an
+any address build one explicitly on the stack and bind to that as any
+other normal flow would do.
+
+Link: https://lore.kernel.org/r/0-v1-9fbb33f5e201+2a-cma_listen_jgg@nvidia.com
+Cc: stable@vger.kernel.org
+Fixes: 732d41c545bb ("RDMA/cma: Make the locking for automatic state transition more clear")
+Reported-by: syzbot+6bb0528b13611047209c@syzkaller.appspotmail.com
+Tested-by: Hao Sun <sunhao.th@gmail.com>
+Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
+Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/infiniband/core/cma.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+--- a/drivers/infiniband/core/cma.c
++++ b/drivers/infiniband/core/cma.c
+@@ -3732,9 +3732,13 @@ int rdma_listen(struct rdma_cm_id *id, i
+ int ret;
+
+ if (!cma_comp_exch(id_priv, RDMA_CM_ADDR_BOUND, RDMA_CM_LISTEN)) {
++ struct sockaddr_in any_in = {
++ .sin_family = AF_INET,
++ .sin_addr.s_addr = htonl(INADDR_ANY),
++ };
++
+ /* For a well behaved ULP state will be RDMA_CM_IDLE */
+- id->route.addr.src_addr.ss_family = AF_INET;
+- ret = rdma_bind_addr(id, cma_src_addr(id_priv));
++ ret = rdma_bind_addr(id, (struct sockaddr *)&any_in);
+ if (ret)
+ return ret;
+ if (WARN_ON(!cma_comp_exch(id_priv, RDMA_CM_ADDR_BOUND,
gpio-pca953x-do-not-ignore-i2c-errors.patch
scsi-ufs-fix-illegal-offset-in-upiu-event-trace.patch
mac80211-fix-use-after-free-in-ccmp-gcmp-rx.patch
+x86-kvmclock-move-this_cpu_pvti-into-kvmclock.h.patch
+kvm-x86-fix-stack-out-of-bounds-memory-access-from-ioapic_write_indirect.patch
+kvm-x86-nsvm-don-t-copy-virt_ext-from-vmcb12.patch
+kvm-nvmx-filter-out-all-unsupported-controls-when-evmcs-was-activated.patch
+kvm-rseq-update-rseq-when-processing-notify_resume-on-xfer-to-kvm-guest.patch
+media-ir_toy-prevent-device-from-hanging-during-transmit.patch
+rdma-cma-do-not-change-route.addr.src_addr.ss_family.patch
+drm-amd-display-pass-pci-deviceid-into-dc.patch
+drm-amdgpu-correct-initial-cp_hqd_quantum-for-gfx9.patch
--- /dev/null
+From ad9af930680bb396c87582edc172b3a7cf2a3fbf Mon Sep 17 00:00:00 2001
+From: Zelin Deng <zelin.deng@linux.alibaba.com>
+Date: Wed, 29 Sep 2021 13:13:48 +0800
+Subject: x86/kvmclock: Move this_cpu_pvti into kvmclock.h
+
+From: Zelin Deng <zelin.deng@linux.alibaba.com>
+
+commit ad9af930680bb396c87582edc172b3a7cf2a3fbf upstream.
+
+There're other modules might use hv_clock_per_cpu variable like ptp_kvm,
+so move it into kvmclock.h and export the symbol to make it visiable to
+other modules.
+
+Signed-off-by: Zelin Deng <zelin.deng@linux.alibaba.com>
+Cc: <stable@vger.kernel.org>
+Message-Id: <1632892429-101194-2-git-send-email-zelin.deng@linux.alibaba.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/include/asm/kvmclock.h | 14 ++++++++++++++
+ arch/x86/kernel/kvmclock.c | 13 ++-----------
+ 2 files changed, 16 insertions(+), 11 deletions(-)
+
+--- a/arch/x86/include/asm/kvmclock.h
++++ b/arch/x86/include/asm/kvmclock.h
+@@ -2,6 +2,20 @@
+ #ifndef _ASM_X86_KVM_CLOCK_H
+ #define _ASM_X86_KVM_CLOCK_H
+
++#include <linux/percpu.h>
++
+ extern struct clocksource kvm_clock;
+
++DECLARE_PER_CPU(struct pvclock_vsyscall_time_info *, hv_clock_per_cpu);
++
++static inline struct pvclock_vcpu_time_info *this_cpu_pvti(void)
++{
++ return &this_cpu_read(hv_clock_per_cpu)->pvti;
++}
++
++static inline struct pvclock_vsyscall_time_info *this_cpu_hvclock(void)
++{
++ return this_cpu_read(hv_clock_per_cpu);
++}
++
+ #endif /* _ASM_X86_KVM_CLOCK_H */
+--- a/arch/x86/kernel/kvmclock.c
++++ b/arch/x86/kernel/kvmclock.c
+@@ -50,18 +50,9 @@ early_param("no-kvmclock-vsyscall", pars
+ static struct pvclock_vsyscall_time_info
+ hv_clock_boot[HVC_BOOT_ARRAY_SIZE] __bss_decrypted __aligned(PAGE_SIZE);
+ static struct pvclock_wall_clock wall_clock __bss_decrypted;
+-static DEFINE_PER_CPU(struct pvclock_vsyscall_time_info *, hv_clock_per_cpu);
+ static struct pvclock_vsyscall_time_info *hvclock_mem;
+-
+-static inline struct pvclock_vcpu_time_info *this_cpu_pvti(void)
+-{
+- return &this_cpu_read(hv_clock_per_cpu)->pvti;
+-}
+-
+-static inline struct pvclock_vsyscall_time_info *this_cpu_hvclock(void)
+-{
+- return this_cpu_read(hv_clock_per_cpu);
+-}
++DEFINE_PER_CPU(struct pvclock_vsyscall_time_info *, hv_clock_per_cpu);
++EXPORT_PER_CPU_SYMBOL_GPL(hv_clock_per_cpu);
+
+ /*
+ * The wallclock is the time of day when we booted. Since then, some time may
projects / thirdparty / kernel / stable-queue.git / commitdiff
