From b99f38494158e1c0f8f78d24a710b315e3448227 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Sun, 3 Oct 2021 16:23:30 +0200 Subject: [PATCH] 5.10-stable patches added patches: drm-amd-display-pass-pci-deviceid-into-dc.patch drm-amdgpu-correct-initial-cp_hqd_quantum-for-gfx9.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 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 media-ir_toy-prevent-device-from-hanging-during-transmit.patch rdma-cma-do-not-change-route.addr.src_addr.ss_family.patch x86-kvmclock-move-this_cpu_pvti-into-kvmclock.h.patch --- ...md-display-pass-pci-deviceid-into-dc.patch | 37 ++++++++ ...rect-initial-cp_hqd_quantum-for-gfx9.patch | 32 +++++++ ...ed-controls-when-evmcs-was-activated.patch | 85 +++++++++++++++++ ...g-notify_resume-on-xfer-to-kvm-guest.patch | 75 +++++++++++++++ ...ry-access-from-ioapic_write_indirect.patch | 91 +++++++++++++++++++ ...nsvm-don-t-copy-virt_ext-from-vmcb12.patch | 34 +++++++ ...-device-from-hanging-during-transmit.patch | 65 +++++++++++++ ...change-route.addr.src_addr.ss_family.patch | 82 +++++++++++++++++ queue-5.10/series | 9 ++ ...k-move-this_cpu_pvti-into-kvmclock.h.patch | 69 ++++++++++++++ 10 files changed, 579 insertions(+) create mode 100644 queue-5.10/drm-amd-display-pass-pci-deviceid-into-dc.patch create mode 100644 queue-5.10/drm-amdgpu-correct-initial-cp_hqd_quantum-for-gfx9.patch create mode 100644 queue-5.10/kvm-nvmx-filter-out-all-unsupported-controls-when-evmcs-was-activated.patch create mode 100644 queue-5.10/kvm-rseq-update-rseq-when-processing-notify_resume-on-xfer-to-kvm-guest.patch create mode 100644 queue-5.10/kvm-x86-fix-stack-out-of-bounds-memory-access-from-ioapic_write_indirect.patch create mode 100644 queue-5.10/kvm-x86-nsvm-don-t-copy-virt_ext-from-vmcb12.patch create mode 100644 queue-5.10/media-ir_toy-prevent-device-from-hanging-during-transmit.patch create mode 100644 queue-5.10/rdma-cma-do-not-change-route.addr.src_addr.ss_family.patch create mode 100644 queue-5.10/x86-kvmclock-move-this_cpu_pvti-into-kvmclock.h.patch diff --git a/queue-5.10/drm-amd-display-pass-pci-deviceid-into-dc.patch b/queue-5.10/drm-amd-display-pass-pci-deviceid-into-dc.patch new file mode 100644 index 00000000000..87d000c5a5c --- /dev/null +++ b/queue-5.10/drm-amd-display-pass-pci-deviceid-into-dc.patch @@ -0,0 +1,37 @@ +From d942856865c733ff60450de9691af796ad71d7bc Mon Sep 17 00:00:00 2001 +From: Charlene Liu +Date: Mon, 20 Sep 2021 14:30:02 -0400 +Subject: drm/amd/display: Pass PCI deviceid into DC + +From: Charlene Liu + +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 +Acked-by: Anson Jacob +Signed-off-by: Charlene Liu +Tested-by: Daniel Wheeler +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + 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!!!! */ diff --git a/queue-5.10/drm-amdgpu-correct-initial-cp_hqd_quantum-for-gfx9.patch b/queue-5.10/drm-amdgpu-correct-initial-cp_hqd_quantum-for-gfx9.patch new file mode 100644 index 00000000000..b77cb44a281 --- /dev/null +++ b/queue-5.10/drm-amdgpu-correct-initial-cp_hqd_quantum-for-gfx9.patch @@ -0,0 +1,32 @@ +From 9f52c25f59b504a29dda42d83ac1e24d2af535d4 Mon Sep 17 00:00:00 2001 +From: Hawking Zhang +Date: Sun, 26 Sep 2021 22:19:35 +0800 +Subject: drm/amdgpu: correct initial cp_hqd_quantum for gfx9 + +From: Hawking Zhang + +commit 9f52c25f59b504a29dda42d83ac1e24d2af535d4 upstream. + +didn't read the value of mmCP_HQD_QUANTUM from correct +register offset + +Signed-off-by: Hawking Zhang +Reviewed-by: Le Ma +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + 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. diff --git a/queue-5.10/kvm-nvmx-filter-out-all-unsupported-controls-when-evmcs-was-activated.patch b/queue-5.10/kvm-nvmx-filter-out-all-unsupported-controls-when-evmcs-was-activated.patch new file mode 100644 index 00000000000..7c9318c5a1c --- /dev/null +++ b/queue-5.10/kvm-nvmx-filter-out-all-unsupported-controls-when-evmcs-was-activated.patch @@ -0,0 +1,85 @@ +From 8d68bad6d869fae8f4d50ab6423538dec7da72d1 Mon Sep 17 00:00:00 2001 +From: Vitaly Kuznetsov +Date: Tue, 7 Sep 2021 18:35:30 +0200 +Subject: KVM: nVMX: Filter out all unsupported controls when eVMCS was activated + +From: Vitaly Kuznetsov + +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 +Message-Id: <20210907163530.110066-1-vkuznets@redhat.com> +Cc: stable@vger.kernel.org +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman +--- + 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) diff --git a/queue-5.10/kvm-rseq-update-rseq-when-processing-notify_resume-on-xfer-to-kvm-guest.patch b/queue-5.10/kvm-rseq-update-rseq-when-processing-notify_resume-on-xfer-to-kvm-guest.patch new file mode 100644 index 00000000000..4ec297b511b --- /dev/null +++ b/queue-5.10/kvm-rseq-update-rseq-when-processing-notify_resume-on-xfer-to-kvm-guest.patch @@ -0,0 +1,75 @@ +From 8646e53633f314e4d746a988240d3b951a92f94a Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +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 + +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 +Bisected-by: Doug Evans +Acked-by: Mathieu Desnoyers +Cc: Shakeel Butt +Cc: Thomas Gleixner +Cc: stable@vger.kernel.org +Signed-off-by: Sean Christopherson +Message-Id: <20210901203030.1292304-2-seanjc@google.com> +Signed-off-by: Paolo Bonzini +[sean: Resolve benign conflict due to unrelated access_ok() check in 5.10] +Signed-off-by: Sean Christopherson +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-5.10/kvm-x86-fix-stack-out-of-bounds-memory-access-from-ioapic_write_indirect.patch b/queue-5.10/kvm-x86-fix-stack-out-of-bounds-memory-access-from-ioapic_write_indirect.patch new file mode 100644 index 00000000000..4ad3d30ae9d --- /dev/null +++ b/queue-5.10/kvm-x86-fix-stack-out-of-bounds-memory-access-from-ioapic_write_indirect.patch @@ -0,0 +1,91 @@ +From 2f9b68f57c6278c322793a06063181deded0ad69 Mon Sep 17 00:00:00 2001 +From: Vitaly Kuznetsov +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 + +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 +Signed-off-by: Vitaly Kuznetsov +Reviewed-by: Maxim Levitsky +Reviewed-by: Sean Christopherson +Message-Id: <20210827092516.1027264-7-vkuznets@redhat.com> +Cc: stable@vger.kernel.org +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman +--- + 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); + } diff --git a/queue-5.10/kvm-x86-nsvm-don-t-copy-virt_ext-from-vmcb12.patch b/queue-5.10/kvm-x86-nsvm-don-t-copy-virt_ext-from-vmcb12.patch new file mode 100644 index 00000000000..92edab04a1c --- /dev/null +++ b/queue-5.10/kvm-x86-nsvm-don-t-copy-virt_ext-from-vmcb12.patch @@ -0,0 +1,34 @@ +From faf6b755629627f19feafa75b32e81cd7738f12d Mon Sep 17 00:00:00 2001 +From: Maxim Levitsky +Date: Tue, 14 Sep 2021 18:48:16 +0300 +Subject: KVM: x86: nSVM: don't copy virt_ext from vmcb12 + +From: Maxim Levitsky + +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 +Message-Id: <20210914154825.104886-6-mlevitsk@redhat.com> +Cc: stable@vger.kernel.org +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-5.10/media-ir_toy-prevent-device-from-hanging-during-transmit.patch b/queue-5.10/media-ir_toy-prevent-device-from-hanging-during-transmit.patch new file mode 100644 index 00000000000..58444deb81d --- /dev/null +++ b/queue-5.10/media-ir_toy-prevent-device-from-hanging-during-transmit.patch @@ -0,0 +1,65 @@ +From f0c15b360fb65ee39849afe987c16eb3d0175d0d Mon Sep 17 00:00:00 2001 +From: Sean Young +Date: Tue, 14 Sep 2021 16:57:46 +0200 +Subject: media: ir_toy: prevent device from hanging during transmit + +From: Sean Young + +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 +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-5.10/rdma-cma-do-not-change-route.addr.src_addr.ss_family.patch b/queue-5.10/rdma-cma-do-not-change-route.addr.src_addr.ss_family.patch new file mode 100644 index 00000000000..eea78a40228 --- /dev/null +++ b/queue-5.10/rdma-cma-do-not-change-route.addr.src_addr.ss_family.patch @@ -0,0 +1,82 @@ +From bc0bdc5afaa740d782fbf936aaeebd65e5c2921d Mon Sep 17 00:00:00 2001 +From: Jason Gunthorpe +Date: Wed, 15 Sep 2021 17:21:43 -0300 +Subject: RDMA/cma: Do not change route.addr.src_addr.ss_family + +From: Jason Gunthorpe + +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 +Reviewed-by: Leon Romanovsky +Signed-off-by: Jason Gunthorpe +Signed-off-by: Greg Kroah-Hartman +--- + 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, diff --git a/queue-5.10/series b/queue-5.10/series index 41bb7ba4893..d0814cc56b9 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -13,3 +13,12 @@ hwmon-w83791d-fix-null-pointer-dereference-by-removing-unnecessary-structure-fie 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 diff --git a/queue-5.10/x86-kvmclock-move-this_cpu_pvti-into-kvmclock.h.patch b/queue-5.10/x86-kvmclock-move-this_cpu_pvti-into-kvmclock.h.patch new file mode 100644 index 00000000000..9e2f5e50c4b --- /dev/null +++ b/queue-5.10/x86-kvmclock-move-this_cpu_pvti-into-kvmclock.h.patch @@ -0,0 +1,69 @@ +From ad9af930680bb396c87582edc172b3a7cf2a3fbf Mon Sep 17 00:00:00 2001 +From: Zelin Deng +Date: Wed, 29 Sep 2021 13:13:48 +0800 +Subject: x86/kvmclock: Move this_cpu_pvti into kvmclock.h + +From: Zelin Deng + +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 +Cc: +Message-Id: <1632892429-101194-2-git-send-email-zelin.deng@linux.alibaba.com> +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman +--- + 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 ++ + 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 -- 2.47.3