commit 27e543cca13fab05689b2d0d61d200a83cfb00b6 Author: Greg Kroah-Hartman Date: Fri Feb 26 10:08:38 2021 +0100 Linux 5.11.2 Tested-by: Jon Hunter Tested-by: Guenter Roeck Tested-by: Shuah Khan Tested-by: Jason Self Tested-by: Ross Schmidt Tested-by: Linux Kernel Functional Testing Link: https://lore.kernel.org/r/20210225092515.015261674@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit e916adf04407c87a15aee2066f75ceb94675d8eb Author: Sean Christopherson Date: Mon Feb 8 12:19:40 2021 -0800 KVM: Use kvm_pfn_t for local PFN variable in hva_to_pfn_remapped() commit a9545779ee9e9e103648f6f2552e73cfe808d0f4 upstream. Use kvm_pfn_t, a.k.a. u64, for the local 'pfn' variable when retrieving a so called "remapped" hva/pfn pair. In theory, the hva could resolve to a pfn in high memory on a 32-bit kernel. This bug was inadvertantly exposed by commit bd2fae8da794 ("KVM: do not assume PTE is writable after follow_pfn"), which added an error PFN value to the mix, causing gcc to comlain about overflowing the unsigned long. arch/x86/kvm/../../../virt/kvm/kvm_main.c: In function ‘hva_to_pfn_remapped’: include/linux/kvm_host.h:89:30: error: conversion from ‘long long unsigned int’ to ‘long unsigned int’ changes value from ‘9218868437227405314’ to ‘2’ [-Werror=overflow] 89 | #define KVM_PFN_ERR_RO_FAULT (KVM_PFN_ERR_MASK + 2) | ^ virt/kvm/kvm_main.c:1935:9: note: in expansion of macro ‘KVM_PFN_ERR_RO_FAULT’ Cc: stable@vger.kernel.org Fixes: add6a0cd1c5b ("KVM: MMU: try to fix up page faults before giving up") Signed-off-by: Sean Christopherson Message-Id: <20210208201940.1258328-1-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit f24380c1fc779d28eea055ec4a8a48a2b9d5559d Author: Paolo Bonzini Date: Fri Feb 5 05:07:11 2021 -0500 mm: provide a saner PTE walking API for modules commit 9fd6dad1261a541b3f5fa7dc5b152222306e6702 upstream. Currently, the follow_pfn function is exported for modules but follow_pte is not. However, follow_pfn is very easy to misuse, because it does not provide protections (so most of its callers assume the page is writable!) and because it returns after having already unlocked the page table lock. Provide instead a simplified version of follow_pte that does not have the pmdpp and range arguments. The older version survives as follow_invalidate_pte() for use by fs/dax.c. Reviewed-by: Jason Gunthorpe Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 9ee03947fcf9632eafe0a060cb04bf377077cdfe Author: Paolo Bonzini Date: Mon Feb 1 05:12:11 2021 -0500 KVM: do not assume PTE is writable after follow_pfn commit bd2fae8da794b55bf2ac02632da3a151b10e664c upstream. In order to convert an HVA to a PFN, KVM usually tries to use the get_user_pages family of functinso. This however is not possible for VM_IO vmas; in that case, KVM instead uses follow_pfn. In doing this however KVM loses the information on whether the PFN is writable. That is usually not a problem because the main use of VM_IO vmas with KVM is for BARs in PCI device assignment, however it is a bug. To fix it, use follow_pte and check pte_write while under the protection of the PTE lock. The information can be used to fail hva_to_pfn_remapped or passed back to the caller via *writable. Usage of follow_pfn was introduced in commit add6a0cd1c5b ("KVM: MMU: try to fix up page faults before giving up", 2016-07-05); however, even older version have the same issue, all the way back to commit 2e2e3738af33 ("KVM: Handle vma regions with no backing page", 2008-07-20), as they also did not check whether the PFN was writable. Fixes: 2e2e3738af33 ("KVM: Handle vma regions with no backing page") Reported-by: David Stevens Cc: 3pvd@google.com Cc: Jann Horn Cc: Jason Gunthorpe Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 06c6164112b13e44e6d16dca29f083d4a89464c1 Author: Sean Christopherson Date: Wed Jan 13 12:50:30 2021 -0800 KVM: x86: Zap the oldest MMU pages, not the newest commit 8fc517267fb28576dfca2380cc2497a2454b8fae upstream. Walk the list of MMU pages in reverse in kvm_mmu_zap_oldest_mmu_pages(). The list is FIFO, meaning new pages are inserted at the head and thus the oldest pages are at the tail. Using a "forward" iterator causes KVM to zap MMU pages that were just added, which obliterates guest performance once the max number of shadow MMU pages is reached. Fixes: 6b82ef2c9cf1 ("KVM: x86/mmu: Batch zap MMU pages when recycling oldest pages") Reported-by: Zdenek Kaspar Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-Id: <20210113205030.3481307-1-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 26dead7b7e39fd009eec7dfc50dac3afc04d2d6e Author: Thomas Hebb Date: Sat Jan 23 18:46:08 2021 -0800 hwmon: (dell-smm) Add XPS 15 L502X to fan control blacklist commit 4008bc7d39537bb3be166d8a3129c4980e1dd7dc upstream. It has been reported[0] that the Dell XPS 15 L502X exhibits similar freezing behavior to the other systems[1] on this blacklist. The issue was exposed by a prior change of mine to automatically load dell_smm_hwmon on a wider set of XPS models. To fix the regression, add this model to the blacklist. [0] https://bugzilla.kernel.org/show_bug.cgi?id=211081 [1] https://bugzilla.kernel.org/show_bug.cgi?id=195751 Fixes: b8a13e5e8f37 ("hwmon: (dell-smm) Use one DMI match for all XPS models") Cc: stable@vger.kernel.org Reported-by: Bob Hepple Tested-by: Bob Hepple Signed-off-by: Thomas Hebb Reviewed-by: Pali Rohár Link: https://lore.kernel.org/r/a09eea7616881d40d2db2fb5fa2770dc6166bdae.1611456351.git.tommyhebb@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 44519dd3b8d0568814ca1690f8dda173f593ee7e Author: Sameer Pujar Date: Thu Jan 7 10:36:10 2021 +0530 arm64: tegra: Add power-domain for Tegra210 HDA commit 1e0ca5467445bc1f41a9e403d6161a22f313dae7 upstream. HDA initialization is failing occasionally on Tegra210 and following print is observed in the boot log. Because of this probe() fails and no sound card is registered. [16.800802] tegra-hda 70030000.hda: no codecs found! Codecs request a state change and enumeration by the controller. In failure cases this does not seem to happen as STATETS register reads 0. The problem seems to be related to the HDA codec dependency on SOR power domain. If it is gated during HDA probe then the failure is observed. Building Tegra HDA driver into kernel image avoids this failure but does not completely address the dependency part. Fix this problem by adding 'power-domains' DT property for Tegra210 HDA. Note that Tegra186 and Tegra194 HDA do this already. Fixes: 742af7e7a0a1 ("arm64: tegra: Add Tegra210 support") Depends-on: 96d1f078ff0 ("arm64: tegra: Add SOR power-domain for Tegra210") Cc: Signed-off-by: Sameer Pujar Acked-by: Jon Hunter Signed-off-by: Thierry Reding Signed-off-by: Greg Kroah-Hartman commit 4a4a0ec8ed3820a43e425c44e5a92e55df84a123 Author: Hui Wang Date: Mon Feb 8 13:02:37 2021 +0800 Bluetooth: btusb: Some Qualcomm Bluetooth adapters stop working commit 234f414efd1164786269849b4fbb533d6c9cdbbf upstream. This issue starts from linux-5.10-rc1, I reproduced this issue on my Dell Inspiron 7447 with BT adapter 0cf3:e005, the kernel will print out: "Bluetooth: hci0: don't support firmware rome 0x31010000", and someone else also reported the similar issue to bugzilla #211571. I found this is a regression introduced by 'commit b40f58b97386 ("Bluetooth: btusb: Add Qualcomm Bluetooth SoC WCN6855 support"), the patch assumed that if high ROM version is not zero, it is an adapter on WCN6855, but many old adapters don't need to load rampatch or nvm, and they have non-zero high ROM version. To fix it, let the driver match the rom_version in the qca_devices_table first, if there is no entry matched, check the high ROM version, if it is not zero, we assume this adapter is ready to work and no need to load rampatch and nvm like previously. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=211571 Fixes: b40f58b97386 ("Bluetooth: btusb: Add Qualcomm Bluetooth SoC WCN6855 support") Signed-off-by: Hui Wang Signed-off-by: Marcel Holtmann Cc: Salvatore Bonaccorso Signed-off-by: Greg Kroah-Hartman commit 6c8e55b1f46bc81e842e99bbe8849540640408af Author: Rustam Kovhaev Date: Wed Feb 24 12:00:30 2021 -0800 ntfs: check for valid standard information attribute commit 4dfe6bd94959222e18d512bdf15f6bf9edb9c27c upstream. Mounting a corrupted filesystem with NTFS resulted in a kernel crash. We should check for valid STANDARD_INFORMATION attribute offset and length before trying to access it Link: https://lkml.kernel.org/r/20210217155930.1506815-1-rkovhaev@gmail.com Link: https://syzkaller.appspot.com/bug?extid=c584225dabdea2f71969 Signed-off-by: Rustam Kovhaev Reported-by: syzbot+c584225dabdea2f71969@syzkaller.appspotmail.com Tested-by: syzbot+c584225dabdea2f71969@syzkaller.appspotmail.com Acked-by: Anton Altaparmakov Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 31d00f071e9197e6550587f480fb0e7cc595a230 Author: Stefan Ursella Date: Wed Feb 10 15:07:11 2021 +0100 usb: quirks: add quirk to start video capture on ELMO L-12F document camera reliable commit 1ebe718bb48278105816ba03a0408ecc2d6cf47f upstream. Without this quirk starting a video capture from the device often fails with kernel: uvcvideo: Failed to set UVC probe control : -110 (exp. 34). Signed-off-by: Stefan Ursella Link: https://lore.kernel.org/r/20210210140713.18711-1-stefan.ursella@wolfvision.net Cc: stable Signed-off-by: Greg Kroah-Hartman commit c102207203346caf3af01ee834d1670e15fb7b2c Author: Johan Hovold Date: Wed Feb 10 12:17:46 2021 +0100 USB: quirks: sort quirk entries commit 43861d29c0810a70792bf69d37482efb7bb6677d upstream. Move the last entry to its proper place to maintain the VID/PID sort order. Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210210111746.13360-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 018cbb2b4472f741eef20b790b13900146ccf224 Author: Will McVicker Date: Sat Dec 5 00:48:48 2020 +0000 HID: make arrays usage and value to be the same commit ed9be64eefe26d7d8b0b5b9fa3ffdf425d87a01f upstream. The HID subsystem allows an "HID report field" to have a different number of "values" and "usages" when it is allocated. When a field struct is created, the size of the usage array is guaranteed to be at least as large as the values array, but it may be larger. This leads to a potential out-of-bounds write in __hidinput_change_resolution_multipliers() and an out-of-bounds read in hidinput_count_leds(). To fix this, let's make sure that both the usage and value arrays are the same size. Cc: stable@vger.kernel.org Signed-off-by: Will McVicker Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 55c262ea5d0f754648cd25aa73de081adaab07d9 Author: Daniel Borkmann Date: Wed Feb 10 14:14:42 2021 +0100 bpf: Fix truncation handling for mod32 dst reg wrt zero commit 9b00f1b78809309163dda2d044d9e94a3c0248a3 upstream. Recently noticed that when mod32 with a known src reg of 0 is performed, then the dst register is 32-bit truncated in verifier: 0: R1=ctx(id=0,off=0,imm=0) R10=fp0 0: (b7) r0 = 0 1: R0_w=inv0 R1=ctx(id=0,off=0,imm=0) R10=fp0 1: (b7) r1 = -1 2: R0_w=inv0 R1_w=inv-1 R10=fp0 2: (b4) w2 = -1 3: R0_w=inv0 R1_w=inv-1 R2_w=inv4294967295 R10=fp0 3: (9c) w1 %= w0 4: R0_w=inv0 R1_w=inv(id=0,umax_value=4294967295,var_off=(0x0; 0xffffffff)) R2_w=inv4294967295 R10=fp0 4: (b7) r0 = 1 5: R0_w=inv1 R1_w=inv(id=0,umax_value=4294967295,var_off=(0x0; 0xffffffff)) R2_w=inv4294967295 R10=fp0 5: (1d) if r1 == r2 goto pc+1 R0_w=inv1 R1_w=inv(id=0,umax_value=4294967295,var_off=(0x0; 0xffffffff)) R2_w=inv4294967295 R10=fp0 6: R0_w=inv1 R1_w=inv(id=0,umax_value=4294967295,var_off=(0x0; 0xffffffff)) R2_w=inv4294967295 R10=fp0 6: (b7) r0 = 2 7: R0_w=inv2 R1_w=inv(id=0,umax_value=4294967295,var_off=(0x0; 0xffffffff)) R2_w=inv4294967295 R10=fp0 7: (95) exit 7: R0=inv1 R1=inv(id=0,umin_value=4294967295,umax_value=4294967295,var_off=(0x0; 0xffffffff)) R2=inv4294967295 R10=fp0 7: (95) exit However, as a runtime result, we get 2 instead of 1, meaning the dst register does not contain (u32)-1 in this case. The reason is fairly straight forward given the 0 test leaves the dst register as-is: # ./bpftool p d x i 23 0: (b7) r0 = 0 1: (b7) r1 = -1 2: (b4) w2 = -1 3: (16) if w0 == 0x0 goto pc+1 4: (9c) w1 %= w0 5: (b7) r0 = 1 6: (1d) if r1 == r2 goto pc+1 7: (b7) r0 = 2 8: (95) exit This was originally not an issue given the dst register was marked as completely unknown (aka 64 bit unknown). However, after 468f6eafa6c4 ("bpf: fix 32-bit ALU op verification") the verifier casts the register output to 32 bit, and hence it becomes 32 bit unknown. Note that for the case where the src register is unknown, the dst register is marked 64 bit unknown. After the fix, the register is truncated by the runtime and the test passes: # ./bpftool p d x i 23 0: (b7) r0 = 0 1: (b7) r1 = -1 2: (b4) w2 = -1 3: (16) if w0 == 0x0 goto pc+2 4: (9c) w1 %= w0 5: (05) goto pc+1 6: (bc) w1 = w1 7: (b7) r0 = 1 8: (1d) if r1 == r2 goto pc+1 9: (b7) r0 = 2 10: (95) exit Semantics also match with {R,W}x mod{64,32} 0 -> {R,W}x. Invalid div has always been {R,W}x div{64,32} 0 -> 0. Rewrites are as follows: mod32: mod64: (16) if w0 == 0x0 goto pc+2 (15) if r0 == 0x0 goto pc+1 (9c) w1 %= w0 (9f) r1 %= r0 (05) goto pc+1 (bc) w1 = w1 Fixes: 468f6eafa6c4 ("bpf: fix 32-bit ALU op verification") Signed-off-by: Daniel Borkmann Reviewed-by: John Fastabend Acked-by: Alexei Starovoitov Signed-off-by: Greg Kroah-Hartman