From: Greg Kroah-Hartman Date: Thu, 25 Feb 2021 09:05:51 +0000 (+0100) Subject: 5.11-stable patches X-Git-Tag: v5.11.2~8 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=ab8846073307dae89f8bf02f751c27a09f15d56b;p=thirdparty%2Fkernel%2Fstable-queue.git 5.11-stable patches added patches: arm64-tegra-add-power-domain-for-tegra210-hda.patch bluetooth-btusb-some-qualcomm-bluetooth-adapters-stop-working.patch hwmon-dell-smm-add-xps-15-l502x-to-fan-control-blacklist.patch kvm-do-not-assume-pte-is-writable-after-follow_pfn.patch kvm-use-kvm_pfn_t-for-local-pfn-variable-in-hva_to_pfn_remapped.patch kvm-x86-zap-the-oldest-mmu-pages-not-the-newest.patch mm-provide-a-saner-pte-walking-api-for-modules.patch ntfs-check-for-valid-standard-information-attribute.patch --- diff --git a/queue-5.11/arm64-tegra-add-power-domain-for-tegra210-hda.patch b/queue-5.11/arm64-tegra-add-power-domain-for-tegra210-hda.patch new file mode 100644 index 00000000000..bb275668024 --- /dev/null +++ b/queue-5.11/arm64-tegra-add-power-domain-for-tegra210-hda.patch @@ -0,0 +1,46 @@ +From 1e0ca5467445bc1f41a9e403d6161a22f313dae7 Mon Sep 17 00:00:00 2001 +From: Sameer Pujar +Date: Thu, 7 Jan 2021 10:36:10 +0530 +Subject: arm64: tegra: Add power-domain for Tegra210 HDA + +From: Sameer Pujar + +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 +--- + arch/arm64/boot/dts/nvidia/tegra210.dtsi | 1 + + 1 file changed, 1 insertion(+) + +--- a/arch/arm64/boot/dts/nvidia/tegra210.dtsi ++++ b/arch/arm64/boot/dts/nvidia/tegra210.dtsi +@@ -997,6 +997,7 @@ + <&tegra_car 128>, /* hda2hdmi */ + <&tegra_car 111>; /* hda2codec_2x */ + reset-names = "hda", "hda2hdmi", "hda2codec_2x"; ++ power-domains = <&pd_sor>; + status = "disabled"; + }; + diff --git a/queue-5.11/bluetooth-btusb-some-qualcomm-bluetooth-adapters-stop-working.patch b/queue-5.11/bluetooth-btusb-some-qualcomm-bluetooth-adapters-stop-working.patch new file mode 100644 index 00000000000..0556f7cad2f --- /dev/null +++ b/queue-5.11/bluetooth-btusb-some-qualcomm-bluetooth-adapters-stop-working.patch @@ -0,0 +1,51 @@ +From 234f414efd1164786269849b4fbb533d6c9cdbbf Mon Sep 17 00:00:00 2001 +From: Hui Wang +Date: Mon, 8 Feb 2021 13:02:37 +0800 +Subject: Bluetooth: btusb: Some Qualcomm Bluetooth adapters stop working + +From: Hui Wang + +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 +--- + drivers/bluetooth/btusb.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +--- a/drivers/bluetooth/btusb.c ++++ b/drivers/bluetooth/btusb.c +@@ -4065,6 +4065,13 @@ static int btusb_setup_qca(struct hci_de + info = &qca_devices_table[i]; + } + if (!info) { ++ /* If the rom_version is not matched in the qca_devices_table ++ * and the high ROM version is not zero, we assume this chip no ++ * need to load the rampatch and nvm. ++ */ ++ if (ver_rom & ~0xffffU) ++ return 0; ++ + bt_dev_err(hdev, "don't support firmware rome 0x%x", ver_rom); + return -ENODEV; + } diff --git a/queue-5.11/hwmon-dell-smm-add-xps-15-l502x-to-fan-control-blacklist.patch b/queue-5.11/hwmon-dell-smm-add-xps-15-l502x-to-fan-control-blacklist.patch new file mode 100644 index 00000000000..c64f24b5c0e --- /dev/null +++ b/queue-5.11/hwmon-dell-smm-add-xps-15-l502x-to-fan-control-blacklist.patch @@ -0,0 +1,50 @@ +From 4008bc7d39537bb3be166d8a3129c4980e1dd7dc Mon Sep 17 00:00:00 2001 +From: Thomas Hebb +Date: Sat, 23 Jan 2021 18:46:08 -0800 +Subject: hwmon: (dell-smm) Add XPS 15 L502X to fan control blacklist +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Thomas Hebb + +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 +--- + drivers/hwmon/dell-smm-hwmon.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +--- a/drivers/hwmon/dell-smm-hwmon.c ++++ b/drivers/hwmon/dell-smm-hwmon.c +@@ -1159,6 +1159,13 @@ static struct dmi_system_id i8k_blacklis + DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "XPS13 9333"), + }, + }, ++ { ++ .ident = "Dell XPS 15 L502X", ++ .matches = { ++ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."), ++ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Dell System XPS L502X"), ++ }, ++ }, + { } + }; + diff --git a/queue-5.11/kvm-do-not-assume-pte-is-writable-after-follow_pfn.patch b/queue-5.11/kvm-do-not-assume-pte-is-writable-after-follow_pfn.patch new file mode 100644 index 00000000000..17de1477f2b --- /dev/null +++ b/queue-5.11/kvm-do-not-assume-pte-is-writable-after-follow_pfn.patch @@ -0,0 +1,85 @@ +From bd2fae8da794b55bf2ac02632da3a151b10e664c Mon Sep 17 00:00:00 2001 +From: Paolo Bonzini +Date: Mon, 1 Feb 2021 05:12:11 -0500 +Subject: KVM: do not assume PTE is writable after follow_pfn + +From: Paolo Bonzini + +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 +--- + virt/kvm/kvm_main.c | 15 ++++++++++++--- + 1 file changed, 12 insertions(+), 3 deletions(-) + +--- a/virt/kvm/kvm_main.c ++++ b/virt/kvm/kvm_main.c +@@ -1904,9 +1904,11 @@ static int hva_to_pfn_remapped(struct vm + kvm_pfn_t *p_pfn) + { + unsigned long pfn; ++ pte_t *ptep; ++ spinlock_t *ptl; + int r; + +- r = follow_pfn(vma, addr, &pfn); ++ r = follow_pte(vma->vm_mm, addr, NULL, &ptep, NULL, &ptl); + if (r) { + /* + * get_user_pages fails for VM_IO and VM_PFNMAP vmas and does +@@ -1921,14 +1923,19 @@ static int hva_to_pfn_remapped(struct vm + if (r) + return r; + +- r = follow_pfn(vma, addr, &pfn); ++ r = follow_pte(vma->vm_mm, addr, NULL, &ptep, NULL, &ptl); + if (r) + return r; ++ } + ++ if (write_fault && !pte_write(*ptep)) { ++ pfn = KVM_PFN_ERR_RO_FAULT; ++ goto out; + } + + if (writable) +- *writable = true; ++ *writable = pte_write(*ptep); ++ pfn = pte_pfn(*ptep); + + /* + * Get a reference here because callers of *hva_to_pfn* and +@@ -1943,6 +1950,8 @@ static int hva_to_pfn_remapped(struct vm + */ + kvm_get_pfn(pfn); + ++out: ++ pte_unmap_unlock(ptep, ptl); + *p_pfn = pfn; + return 0; + } diff --git a/queue-5.11/kvm-use-kvm_pfn_t-for-local-pfn-variable-in-hva_to_pfn_remapped.patch b/queue-5.11/kvm-use-kvm_pfn_t-for-local-pfn-variable-in-hva_to_pfn_remapped.patch new file mode 100644 index 00000000000..88029f522ba --- /dev/null +++ b/queue-5.11/kvm-use-kvm_pfn_t-for-local-pfn-variable-in-hva_to_pfn_remapped.patch @@ -0,0 +1,49 @@ +From a9545779ee9e9e103648f6f2552e73cfe808d0f4 Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Mon, 8 Feb 2021 12:19:40 -0800 +Subject: KVM: Use kvm_pfn_t for local PFN variable in hva_to_pfn_remapped() +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Sean Christopherson + +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 +--- + virt/kvm/kvm_main.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/virt/kvm/kvm_main.c ++++ b/virt/kvm/kvm_main.c +@@ -1903,7 +1903,7 @@ static int hva_to_pfn_remapped(struct vm + bool write_fault, bool *writable, + kvm_pfn_t *p_pfn) + { +- unsigned long pfn; ++ kvm_pfn_t pfn; + pte_t *ptep; + spinlock_t *ptl; + int r; diff --git a/queue-5.11/kvm-x86-zap-the-oldest-mmu-pages-not-the-newest.patch b/queue-5.11/kvm-x86-zap-the-oldest-mmu-pages-not-the-newest.patch new file mode 100644 index 00000000000..b92b722fc27 --- /dev/null +++ b/queue-5.11/kvm-x86-zap-the-oldest-mmu-pages-not-the-newest.patch @@ -0,0 +1,37 @@ +From 8fc517267fb28576dfca2380cc2497a2454b8fae Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Wed, 13 Jan 2021 12:50:30 -0800 +Subject: KVM: x86: Zap the oldest MMU pages, not the newest + +From: Sean Christopherson + +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 +--- + arch/x86/kvm/mmu/mmu.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/x86/kvm/mmu/mmu.c ++++ b/arch/x86/kvm/mmu/mmu.c +@@ -2417,7 +2417,7 @@ static unsigned long kvm_mmu_zap_oldest_ + return 0; + + restart: +- list_for_each_entry_safe(sp, tmp, &kvm->arch.active_mmu_pages, link) { ++ list_for_each_entry_safe_reverse(sp, tmp, &kvm->arch.active_mmu_pages, link) { + /* + * Don't zap active root pages, the page itself can't be freed + * and zapping it will just force vCPUs to realloc and reload. diff --git a/queue-5.11/mm-provide-a-saner-pte-walking-api-for-modules.patch b/queue-5.11/mm-provide-a-saner-pte-walking-api-for-modules.patch new file mode 100644 index 00000000000..03aa0149bcd --- /dev/null +++ b/queue-5.11/mm-provide-a-saner-pte-walking-api-for-modules.patch @@ -0,0 +1,181 @@ +From 9fd6dad1261a541b3f5fa7dc5b152222306e6702 Mon Sep 17 00:00:00 2001 +From: Paolo Bonzini +Date: Fri, 5 Feb 2021 05:07:11 -0500 +Subject: mm: provide a saner PTE walking API for modules + +From: Paolo Bonzini + +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 +--- + arch/s390/pci/pci_mmio.c | 4 ++-- + fs/dax.c | 5 +++-- + include/linux/mm.h | 6 ++++-- + mm/memory.c | 41 ++++++++++++++++++++++++++++++++++++----- + virt/kvm/kvm_main.c | 4 ++-- + 5 files changed, 47 insertions(+), 13 deletions(-) + +--- a/arch/s390/pci/pci_mmio.c ++++ b/arch/s390/pci/pci_mmio.c +@@ -170,7 +170,7 @@ SYSCALL_DEFINE3(s390_pci_mmio_write, uns + if (!(vma->vm_flags & VM_WRITE)) + goto out_unlock_mmap; + +- ret = follow_pte(vma->vm_mm, mmio_addr, NULL, &ptep, NULL, &ptl); ++ ret = follow_pte(vma->vm_mm, mmio_addr, &ptep, &ptl); + if (ret) + goto out_unlock_mmap; + +@@ -311,7 +311,7 @@ SYSCALL_DEFINE3(s390_pci_mmio_read, unsi + if (!(vma->vm_flags & VM_WRITE)) + goto out_unlock_mmap; + +- ret = follow_pte(vma->vm_mm, mmio_addr, NULL, &ptep, NULL, &ptl); ++ ret = follow_pte(vma->vm_mm, mmio_addr, &ptep, &ptl); + if (ret) + goto out_unlock_mmap; + +--- a/fs/dax.c ++++ b/fs/dax.c +@@ -810,11 +810,12 @@ static void dax_entry_mkclean(struct add + address = pgoff_address(index, vma); + + /* +- * Note because we provide range to follow_pte it will call ++ * follow_invalidate_pte() will use the range to call + * mmu_notifier_invalidate_range_start() on our behalf before + * taking any lock. + */ +- if (follow_pte(vma->vm_mm, address, &range, &ptep, &pmdp, &ptl)) ++ if (follow_invalidate_pte(vma->vm_mm, address, &range, &ptep, ++ &pmdp, &ptl)) + continue; + + /* +--- a/include/linux/mm.h ++++ b/include/linux/mm.h +@@ -1658,9 +1658,11 @@ void free_pgd_range(struct mmu_gather *t + unsigned long end, unsigned long floor, unsigned long ceiling); + int + copy_page_range(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma); ++int follow_invalidate_pte(struct mm_struct *mm, unsigned long address, ++ struct mmu_notifier_range *range, pte_t **ptepp, ++ pmd_t **pmdpp, spinlock_t **ptlp); + int follow_pte(struct mm_struct *mm, unsigned long address, +- struct mmu_notifier_range *range, pte_t **ptepp, pmd_t **pmdpp, +- spinlock_t **ptlp); ++ pte_t **ptepp, spinlock_t **ptlp); + int follow_pfn(struct vm_area_struct *vma, unsigned long address, + unsigned long *pfn); + int follow_phys(struct vm_area_struct *vma, unsigned long address, +--- a/mm/memory.c ++++ b/mm/memory.c +@@ -4709,9 +4709,9 @@ int __pmd_alloc(struct mm_struct *mm, pu + } + #endif /* __PAGETABLE_PMD_FOLDED */ + +-int follow_pte(struct mm_struct *mm, unsigned long address, +- struct mmu_notifier_range *range, pte_t **ptepp, pmd_t **pmdpp, +- spinlock_t **ptlp) ++int follow_invalidate_pte(struct mm_struct *mm, unsigned long address, ++ struct mmu_notifier_range *range, pte_t **ptepp, ++ pmd_t **pmdpp, spinlock_t **ptlp) + { + pgd_t *pgd; + p4d_t *p4d; +@@ -4777,6 +4777,34 @@ out: + } + + /** ++ * follow_pte - look up PTE at a user virtual address ++ * @mm: the mm_struct of the target address space ++ * @address: user virtual address ++ * @ptepp: location to store found PTE ++ * @ptlp: location to store the lock for the PTE ++ * ++ * On a successful return, the pointer to the PTE is stored in @ptepp; ++ * the corresponding lock is taken and its location is stored in @ptlp. ++ * The contents of the PTE are only stable until @ptlp is released; ++ * any further use, if any, must be protected against invalidation ++ * with MMU notifiers. ++ * ++ * Only IO mappings and raw PFN mappings are allowed. The mmap semaphore ++ * should be taken for read. ++ * ++ * KVM uses this function. While it is arguably less bad than ``follow_pfn``, ++ * it is not a good general-purpose API. ++ * ++ * Return: zero on success, -ve otherwise. ++ */ ++int follow_pte(struct mm_struct *mm, unsigned long address, ++ pte_t **ptepp, spinlock_t **ptlp) ++{ ++ return follow_invalidate_pte(mm, address, NULL, ptepp, NULL, ptlp); ++} ++EXPORT_SYMBOL_GPL(follow_pte); ++ ++/** + * follow_pfn - look up PFN at a user virtual address + * @vma: memory mapping + * @address: user virtual address +@@ -4784,6 +4812,9 @@ out: + * + * Only IO mappings and raw PFN mappings are allowed. + * ++ * This function does not allow the caller to read the permissions ++ * of the PTE. Do not use it. ++ * + * Return: zero and the pfn at @pfn on success, -ve otherwise. + */ + int follow_pfn(struct vm_area_struct *vma, unsigned long address, +@@ -4796,7 +4827,7 @@ int follow_pfn(struct vm_area_struct *vm + if (!(vma->vm_flags & (VM_IO | VM_PFNMAP))) + return ret; + +- ret = follow_pte(vma->vm_mm, address, NULL, &ptep, NULL, &ptl); ++ ret = follow_pte(vma->vm_mm, address, &ptep, &ptl); + if (ret) + return ret; + *pfn = pte_pfn(*ptep); +@@ -4817,7 +4848,7 @@ int follow_phys(struct vm_area_struct *v + if (!(vma->vm_flags & (VM_IO | VM_PFNMAP))) + goto out; + +- if (follow_pte(vma->vm_mm, address, NULL, &ptep, NULL, &ptl)) ++ if (follow_pte(vma->vm_mm, address, &ptep, &ptl)) + goto out; + pte = *ptep; + +--- a/virt/kvm/kvm_main.c ++++ b/virt/kvm/kvm_main.c +@@ -1908,7 +1908,7 @@ static int hva_to_pfn_remapped(struct vm + spinlock_t *ptl; + int r; + +- r = follow_pte(vma->vm_mm, addr, NULL, &ptep, NULL, &ptl); ++ r = follow_pte(vma->vm_mm, addr, &ptep, &ptl); + if (r) { + /* + * get_user_pages fails for VM_IO and VM_PFNMAP vmas and does +@@ -1923,7 +1923,7 @@ static int hva_to_pfn_remapped(struct vm + if (r) + return r; + +- r = follow_pte(vma->vm_mm, addr, NULL, &ptep, NULL, &ptl); ++ r = follow_pte(vma->vm_mm, addr, &ptep, &ptl); + if (r) + return r; + } diff --git a/queue-5.11/ntfs-check-for-valid-standard-information-attribute.patch b/queue-5.11/ntfs-check-for-valid-standard-information-attribute.patch new file mode 100644 index 00000000000..72f0d3c1d79 --- /dev/null +++ b/queue-5.11/ntfs-check-for-valid-standard-information-attribute.patch @@ -0,0 +1,43 @@ +From 4dfe6bd94959222e18d512bdf15f6bf9edb9c27c Mon Sep 17 00:00:00 2001 +From: Rustam Kovhaev +Date: Wed, 24 Feb 2021 12:00:30 -0800 +Subject: ntfs: check for valid standard information attribute + +From: Rustam Kovhaev + +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 +--- + fs/ntfs/inode.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +--- a/fs/ntfs/inode.c ++++ b/fs/ntfs/inode.c +@@ -629,6 +629,12 @@ static int ntfs_read_locked_inode(struct + } + a = ctx->attr; + /* Get the standard information attribute value. */ ++ if ((u8 *)a + le16_to_cpu(a->data.resident.value_offset) ++ + le32_to_cpu(a->data.resident.value_length) > ++ (u8 *)ctx->mrec + vol->mft_record_size) { ++ ntfs_error(vi->i_sb, "Corrupt standard information attribute in inode."); ++ goto unm_err_out; ++ } + si = (STANDARD_INFORMATION*)((u8*)a + + le16_to_cpu(a->data.resident.value_offset)); + diff --git a/queue-5.11/series b/queue-5.11/series index b4fe32a0aa7..82ee129729d 100644 --- a/queue-5.11/series +++ b/queue-5.11/series @@ -2,3 +2,11 @@ bpf-fix-truncation-handling-for-mod32-dst-reg-wrt-zero.patch hid-make-arrays-usage-and-value-to-be-the-same.patch usb-quirks-sort-quirk-entries.patch usb-quirks-add-quirk-to-start-video-capture-on-elmo-l-12f-document-camera-reliable.patch +ntfs-check-for-valid-standard-information-attribute.patch +bluetooth-btusb-some-qualcomm-bluetooth-adapters-stop-working.patch +arm64-tegra-add-power-domain-for-tegra210-hda.patch +hwmon-dell-smm-add-xps-15-l502x-to-fan-control-blacklist.patch +kvm-x86-zap-the-oldest-mmu-pages-not-the-newest.patch +kvm-do-not-assume-pte-is-writable-after-follow_pfn.patch +mm-provide-a-saner-pte-walking-api-for-modules.patch +kvm-use-kvm_pfn_t-for-local-pfn-variable-in-hva_to_pfn_remapped.patch