From 621ce026ab00c0d2ae89513c8215872fae65697d Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Mon, 21 Nov 2022 13:18:39 +0100 Subject: [PATCH] 6.0-stable patches added patches: blk-cgroup-properly-pin-the-parent-in-blkcg_css_online.patch docs-driver-api-miscellaneous-remove-kernel-doc-of-serial_core.c.patch docs-update-mediator-contact-information-in-coc-doc.patch firmware-coreboot-register-bus-in-module-init.patch iommu-vt-d-preset-access-bit-for-iova-in-fl-non-leaf-paging-entries.patch iommu-vt-d-set-sre-bit-only-when-hardware-has-srs-cap.patch misc-vmw_vmci-fix-an-infoleak-in-vmci_host_do_receive_datagram.patch mmc-core-properly-select-voltage-range-without-power-cycle.patch mmc-sdhci-pci-fix-possible-memory-leak-caused-by-missing-pci_dev_put.patch mmc-sdhci-pci-o2micro-fix-card-detect-fail-issue-caused-by-cd-debounce-timeout.patch perf-x86-amd-uncore-fix-memory-leak-for-events-array.patch perf-x86-intel-pt-fix-sampling-using-single-range-output.patch s390-dcssblk-fix-deadlock-when-adding-a-dcss.patch x86-fpu-drop-fpregs-lock-before-inheriting-fpu-permissions.patch x86-sgx-add-overflow-check-in-sgx_validate_offset_length.patch --- ...y-pin-the-parent-in-blkcg_css_online.patch | 37 +++++ ...s-remove-kernel-doc-of-serial_core.c.patch | 53 ++++++++ ...iator-contact-information-in-coc-doc.patch | 30 ++++ ...coreboot-register-bus-in-module-init.patch | 128 ++++++++++++++++++ ...r-iova-in-fl-non-leaf-paging-entries.patch | 52 +++++++ ...e-bit-only-when-hardware-has-srs-cap.patch | 57 ++++++++ ...eak-in-vmci_host_do_receive_datagram.patch | 77 +++++++++++ ...ct-voltage-range-without-power-cycle.patch | 47 +++++++ ...y-leak-caused-by-missing-pci_dev_put.patch | 36 +++++ ...-issue-caused-by-cd-debounce-timeout.patch | 45 ++++++ ...ore-fix-memory-leak-for-events-array.patch | 78 +++++++++++ ...x-sampling-using-single-range-output.patch | 41 ++++++ ...sblk-fix-deadlock-when-adding-a-dcss.patch | 47 +++++++ queue-6.0/series | 15 ++ ...ck-before-inheriting-fpu-permissions.patch | 101 ++++++++++++++ ...-check-in-sgx_validate_offset_length.patch | 39 ++++++ 16 files changed, 883 insertions(+) create mode 100644 queue-6.0/blk-cgroup-properly-pin-the-parent-in-blkcg_css_online.patch create mode 100644 queue-6.0/docs-driver-api-miscellaneous-remove-kernel-doc-of-serial_core.c.patch create mode 100644 queue-6.0/docs-update-mediator-contact-information-in-coc-doc.patch create mode 100644 queue-6.0/firmware-coreboot-register-bus-in-module-init.patch create mode 100644 queue-6.0/iommu-vt-d-preset-access-bit-for-iova-in-fl-non-leaf-paging-entries.patch create mode 100644 queue-6.0/iommu-vt-d-set-sre-bit-only-when-hardware-has-srs-cap.patch create mode 100644 queue-6.0/misc-vmw_vmci-fix-an-infoleak-in-vmci_host_do_receive_datagram.patch create mode 100644 queue-6.0/mmc-core-properly-select-voltage-range-without-power-cycle.patch create mode 100644 queue-6.0/mmc-sdhci-pci-fix-possible-memory-leak-caused-by-missing-pci_dev_put.patch create mode 100644 queue-6.0/mmc-sdhci-pci-o2micro-fix-card-detect-fail-issue-caused-by-cd-debounce-timeout.patch create mode 100644 queue-6.0/perf-x86-amd-uncore-fix-memory-leak-for-events-array.patch create mode 100644 queue-6.0/perf-x86-intel-pt-fix-sampling-using-single-range-output.patch create mode 100644 queue-6.0/s390-dcssblk-fix-deadlock-when-adding-a-dcss.patch create mode 100644 queue-6.0/x86-fpu-drop-fpregs-lock-before-inheriting-fpu-permissions.patch create mode 100644 queue-6.0/x86-sgx-add-overflow-check-in-sgx_validate_offset_length.patch diff --git a/queue-6.0/blk-cgroup-properly-pin-the-parent-in-blkcg_css_online.patch b/queue-6.0/blk-cgroup-properly-pin-the-parent-in-blkcg_css_online.patch new file mode 100644 index 00000000000..a28a37355a4 --- /dev/null +++ b/queue-6.0/blk-cgroup-properly-pin-the-parent-in-blkcg_css_online.patch @@ -0,0 +1,37 @@ +From d7dbd43f4a828fa1d9a8614d5b0ac40aee6375fe Mon Sep 17 00:00:00 2001 +From: Chris Mason +Date: Mon, 14 Nov 2022 10:19:30 -0800 +Subject: blk-cgroup: properly pin the parent in blkcg_css_online + +From: Chris Mason + +commit d7dbd43f4a828fa1d9a8614d5b0ac40aee6375fe upstream. + +blkcg_css_online is supposed to pin the blkcg of the parent, but +397c9f46ee4d refactored things and along the way, changed it to pin the +css instead. This results in extra pins, and we end up leaking blkcgs +and cgroups. + +Fixes: 397c9f46ee4d ("blk-cgroup: move blkcg_{pin,unpin}_online out of line") +Signed-off-by: Chris Mason +Spotted-by: Rik van Riel +Cc: # v5.19+ +Acked-by: Johannes Weiner +Link: https://lore.kernel.org/r/20221114181930.2093706-1-clm@fb.com +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman +--- + block/blk-cgroup.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/block/blk-cgroup.c ++++ b/block/blk-cgroup.c +@@ -1251,7 +1251,7 @@ static int blkcg_css_online(struct cgrou + * parent so that offline always happens towards the root. + */ + if (parent) +- blkcg_pin_online(css); ++ blkcg_pin_online(&parent->css); + return 0; + } + diff --git a/queue-6.0/docs-driver-api-miscellaneous-remove-kernel-doc-of-serial_core.c.patch b/queue-6.0/docs-driver-api-miscellaneous-remove-kernel-doc-of-serial_core.c.patch new file mode 100644 index 00000000000..0b57ba4cde1 --- /dev/null +++ b/queue-6.0/docs-driver-api-miscellaneous-remove-kernel-doc-of-serial_core.c.patch @@ -0,0 +1,53 @@ +From 3ec17cb325ac731c2211e13f7eaa4b812694e218 Mon Sep 17 00:00:00 2001 +From: Akira Yokosawa +Date: Wed, 2 Nov 2022 20:48:01 +0900 +Subject: docs/driver-api/miscellaneous: Remove kernel-doc of serial_core.c + +From: Akira Yokosawa + +commit 3ec17cb325ac731c2211e13f7eaa4b812694e218 upstream. + +Since merge of tty-6.0-rc1, "make htmldocs" with Sphinx >=3.1 emits +a bunch of warnings indicating duplicate kernel-doc comments from +drivers/tty/serial/serial_core.c. + +This is due to the kernel-doc directive for serial_core.c in +serial/drivers.rst added in the merge. It conflicts with an existing +kernel-doc directive in miscellaneous.rst. + +Remove the latter directive and resolve the duplicates. + +Signed-off-by: Akira Yokosawa +Fixes: 607ca0f742b7 ("Merge tag 'tty-6.0-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty") +Cc: stable@vger.kernel.org # 6.0 +Cc: Jiri Slaby +Cc: Greg Kroah-Hartman +Reviewed-by: Jiri Slaby +Link: https://lore.kernel.org/r/4e54c76a-138a-07e0-985a-dd83cb622208@gmail.com +Signed-off-by: Greg Kroah-Hartman +--- + Documentation/driver-api/miscellaneous.rst | 5 ++--- + 1 file changed, 2 insertions(+), 3 deletions(-) + +diff --git a/Documentation/driver-api/miscellaneous.rst b/Documentation/driver-api/miscellaneous.rst +index 304ffb146cf9..4a5104a368ac 100644 +--- a/Documentation/driver-api/miscellaneous.rst ++++ b/Documentation/driver-api/miscellaneous.rst +@@ -16,12 +16,11 @@ Parallel Port Devices + 16x50 UART Driver + ================= + +-.. kernel-doc:: drivers/tty/serial/serial_core.c +- :export: +- + .. kernel-doc:: drivers/tty/serial/8250/8250_core.c + :export: + ++See serial/driver.rst for related APIs. ++ + Pulse-Width Modulation (PWM) + ============================ + +-- +2.38.1 + diff --git a/queue-6.0/docs-update-mediator-contact-information-in-coc-doc.patch b/queue-6.0/docs-update-mediator-contact-information-in-coc-doc.patch new file mode 100644 index 00000000000..5bcdaaf010f --- /dev/null +++ b/queue-6.0/docs-update-mediator-contact-information-in-coc-doc.patch @@ -0,0 +1,30 @@ +From 5fddf8962b429b8303c4a654291ecb6e61a7d747 Mon Sep 17 00:00:00 2001 +From: Shuah Khan +Date: Tue, 11 Oct 2022 11:14:17 -0600 +Subject: docs: update mediator contact information in CoC doc + +From: Shuah Khan + +commit 5fddf8962b429b8303c4a654291ecb6e61a7d747 upstream. + +Update mediator contact information in CoC interpretation document. + +Cc: +Signed-off-by: Shuah Khan +Link: https://lore.kernel.org/r/20221011171417.34286-1-skhan@linuxfoundation.org +Signed-off-by: Greg Kroah-Hartman +--- + Documentation/process/code-of-conduct-interpretation.rst | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/Documentation/process/code-of-conduct-interpretation.rst ++++ b/Documentation/process/code-of-conduct-interpretation.rst +@@ -51,7 +51,7 @@ the Technical Advisory Board (TAB) or ot + uncertain how to handle situations that come up. It will not be + considered a violation report unless you want it to be. If you are + uncertain about approaching the TAB or any other maintainers, please +-reach out to our conflict mediator, Joanna Lee . ++reach out to our conflict mediator, Joanna Lee . + + In the end, "be kind to each other" is really what the end goal is for + everybody. We know everyone is human and we all fail at times, but the diff --git a/queue-6.0/firmware-coreboot-register-bus-in-module-init.patch b/queue-6.0/firmware-coreboot-register-bus-in-module-init.patch new file mode 100644 index 00000000000..993ae32fdb8 --- /dev/null +++ b/queue-6.0/firmware-coreboot-register-bus-in-module-init.patch @@ -0,0 +1,128 @@ +From 65946690ed8d972fdb91a74ee75ac0f0f0d68321 Mon Sep 17 00:00:00 2001 +From: Brian Norris +Date: Wed, 19 Oct 2022 18:10:53 -0700 +Subject: firmware: coreboot: Register bus in module init + +From: Brian Norris + +commit 65946690ed8d972fdb91a74ee75ac0f0f0d68321 upstream. + +The coreboot_table driver registers a coreboot bus while probing a +"coreboot_table" device representing the coreboot table memory region. +Probing this device (i.e., registering the bus) is a dependency for the +module_init() functions of any driver for this bus (e.g., +memconsole-coreboot.c / memconsole_driver_init()). + +With synchronous probe, this dependency works OK, as the link order in +the Makefile ensures coreboot_table_driver_init() (and thus, +coreboot_table_probe()) completes before a coreboot device driver tries +to add itself to the bus. + +With asynchronous probe, however, coreboot_table_probe() may race with +memconsole_driver_init(), and so we're liable to hit one of these two: + +1. coreboot_driver_register() eventually hits "[...] the bus was not + initialized.", and the memconsole driver fails to register; or +2. coreboot_driver_register() gets past #1, but still races with + bus_register() and hits some other undefined/crashing behavior (e.g., + in driver_find() [1]) + +We can resolve this by registering the bus in our initcall, and only +deferring "device" work (scanning the coreboot memory region and +creating sub-devices) to probe(). + +[1] Example failure, using 'driver_async_probe=*' kernel command line: + +[ 0.114217] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 +... +[ 0.114307] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.1.0-rc1 #63 +[ 0.114316] Hardware name: Google Scarlet (DT) +... +[ 0.114488] Call trace: +[ 0.114494] _raw_spin_lock+0x34/0x60 +[ 0.114502] kset_find_obj+0x28/0x84 +[ 0.114511] driver_find+0x30/0x50 +[ 0.114520] driver_register+0x64/0x10c +[ 0.114528] coreboot_driver_register+0x30/0x3c +[ 0.114540] memconsole_driver_init+0x24/0x30 +[ 0.114550] do_one_initcall+0x154/0x2e0 +[ 0.114560] do_initcall_level+0x134/0x160 +[ 0.114571] do_initcalls+0x60/0xa0 +[ 0.114579] do_basic_setup+0x28/0x34 +[ 0.114588] kernel_init_freeable+0xf8/0x150 +[ 0.114596] kernel_init+0x2c/0x12c +[ 0.114607] ret_from_fork+0x10/0x20 +[ 0.114624] Code: 5280002b 1100054a b900092a f9800011 (885ffc01) +[ 0.114631] ---[ end trace 0000000000000000 ]--- + +Fixes: b81e3140e412 ("firmware: coreboot: Make bus registration symmetric") +Cc: +Signed-off-by: Brian Norris +Reviewed-by: Guenter Roeck +Reviewed-by: Stephen Boyd +Link: https://lore.kernel.org/r/20221019180934.1.If29e167d8a4771b0bf4a39c89c6946ed764817b9@changeid +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Greg Kroah-Hartman +--- + drivers/firmware/google/coreboot_table.c | 37 ++++++++++++++++++++++++------- + 1 file changed, 29 insertions(+), 8 deletions(-) + +--- a/drivers/firmware/google/coreboot_table.c ++++ b/drivers/firmware/google/coreboot_table.c +@@ -149,12 +149,8 @@ static int coreboot_table_probe(struct p + if (!ptr) + return -ENOMEM; + +- ret = bus_register(&coreboot_bus_type); +- if (!ret) { +- ret = coreboot_table_populate(dev, ptr); +- if (ret) +- bus_unregister(&coreboot_bus_type); +- } ++ ret = coreboot_table_populate(dev, ptr); ++ + memunmap(ptr); + + return ret; +@@ -169,7 +165,6 @@ static int __cb_dev_unregister(struct de + static int coreboot_table_remove(struct platform_device *pdev) + { + bus_for_each_dev(&coreboot_bus_type, NULL, NULL, __cb_dev_unregister); +- bus_unregister(&coreboot_bus_type); + return 0; + } + +@@ -199,6 +194,32 @@ static struct platform_driver coreboot_t + .of_match_table = of_match_ptr(coreboot_of_match), + }, + }; +-module_platform_driver(coreboot_table_driver); ++ ++static int __init coreboot_table_driver_init(void) ++{ ++ int ret; ++ ++ ret = bus_register(&coreboot_bus_type); ++ if (ret) ++ return ret; ++ ++ ret = platform_driver_register(&coreboot_table_driver); ++ if (ret) { ++ bus_unregister(&coreboot_bus_type); ++ return ret; ++ } ++ ++ return 0; ++} ++ ++static void __exit coreboot_table_driver_exit(void) ++{ ++ platform_driver_unregister(&coreboot_table_driver); ++ bus_unregister(&coreboot_bus_type); ++} ++ ++module_init(coreboot_table_driver_init); ++module_exit(coreboot_table_driver_exit); ++ + MODULE_AUTHOR("Google, Inc."); + MODULE_LICENSE("GPL"); diff --git a/queue-6.0/iommu-vt-d-preset-access-bit-for-iova-in-fl-non-leaf-paging-entries.patch b/queue-6.0/iommu-vt-d-preset-access-bit-for-iova-in-fl-non-leaf-paging-entries.patch new file mode 100644 index 00000000000..cb4c1b07538 --- /dev/null +++ b/queue-6.0/iommu-vt-d-preset-access-bit-for-iova-in-fl-non-leaf-paging-entries.patch @@ -0,0 +1,52 @@ +From 242b0aaeabbe2efbef1b9d42a8e56627e800964c Mon Sep 17 00:00:00 2001 +From: Tina Zhang +Date: Wed, 16 Nov 2022 13:15:43 +0800 +Subject: iommu/vt-d: Preset Access bit for IOVA in FL non-leaf paging entries + +From: Tina Zhang + +commit 242b0aaeabbe2efbef1b9d42a8e56627e800964c upstream. + +The A/D bits are preseted for IOVA over first level(FL) usage for both +kernel DMA (i.e, domain typs is IOMMU_DOMAIN_DMA) and user space DMA +usage (i.e., domain type is IOMMU_DOMAIN_UNMANAGED). + +Presetting A bit in FL requires to preset the bit in every related paging +entries, including the non-leaf ones. Otherwise, hardware may treat this +as an error. For example, in a case of ECAP_REG.SMPWC==0, DMA faults might +occur with below DMAR fault messages (wrapped for line length) dumped. + + DMAR: DRHD: handling fault status reg 2 + DMAR: [DMA Read NO_PASID] Request device [aa:00.0] fault addr 0x10c3a6000 + [fault reason 0x90] + SM: A/D bit update needed in first-level entry when set up in no snoop + +Fixes: 289b3b005cb9 ("iommu/vt-d: Preset A/D bits for user space DMA usage") +Cc: stable@vger.kernel.org +Signed-off-by: Tina Zhang +Link: https://lore.kernel.org/r/20221113010324.1094483-1-tina.zhang@intel.com +Signed-off-by: Lu Baolu +Link: https://lore.kernel.org/r/20221116051544.26540-2-baolu.lu@linux.intel.com +Signed-off-by: Joerg Roedel +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iommu/intel/iommu.c | 8 +++----- + 1 file changed, 3 insertions(+), 5 deletions(-) + +--- a/drivers/iommu/intel/iommu.c ++++ b/drivers/iommu/intel/iommu.c +@@ -954,11 +954,9 @@ static struct dma_pte *pfn_to_dma_pte(st + + domain_flush_cache(domain, tmp_page, VTD_PAGE_SIZE); + pteval = ((uint64_t)virt_to_dma_pfn(tmp_page) << VTD_PAGE_SHIFT) | DMA_PTE_READ | DMA_PTE_WRITE; +- if (domain_use_first_level(domain)) { +- pteval |= DMA_FL_PTE_XD | DMA_FL_PTE_US; +- if (iommu_is_dma_domain(&domain->domain)) +- pteval |= DMA_FL_PTE_ACCESS; +- } ++ if (domain_use_first_level(domain)) ++ pteval |= DMA_FL_PTE_XD | DMA_FL_PTE_US | DMA_FL_PTE_ACCESS; ++ + if (cmpxchg64(&pte->val, 0ULL, pteval)) + /* Someone else set it while we were thinking; use theirs. */ + free_pgtable_page(tmp_page); diff --git a/queue-6.0/iommu-vt-d-set-sre-bit-only-when-hardware-has-srs-cap.patch b/queue-6.0/iommu-vt-d-set-sre-bit-only-when-hardware-has-srs-cap.patch new file mode 100644 index 00000000000..6161a8b3d91 --- /dev/null +++ b/queue-6.0/iommu-vt-d-set-sre-bit-only-when-hardware-has-srs-cap.patch @@ -0,0 +1,57 @@ +From 7fc961cf7ffcb130c4e93ee9a5628134f9de700a Mon Sep 17 00:00:00 2001 +From: Tina Zhang +Date: Wed, 16 Nov 2022 13:15:44 +0800 +Subject: iommu/vt-d: Set SRE bit only when hardware has SRS cap + +From: Tina Zhang + +commit 7fc961cf7ffcb130c4e93ee9a5628134f9de700a upstream. + +SRS cap is the hardware cap telling if the hardware IOMMU can support +requests seeking supervisor privilege or not. SRE bit in scalable-mode +PASID table entry is treated as Reserved(0) for implementation not +supporting SRS cap. + +Checking SRS cap before setting SRE bit can avoid the non-recoverable +fault of "Non-zero reserved field set in PASID Table Entry" caused by +setting SRE bit while there is no SRS cap support. The fault messages +look like below: + + DMAR: DRHD: handling fault status reg 2 + DMAR: [DMA Read NO_PASID] Request device [00:0d.0] fault addr 0x1154e1000 + [fault reason 0x5a] + SM: Non-zero reserved field set in PASID Table Entry + +Fixes: 6f7db75e1c46 ("iommu/vt-d: Add second level page table interface") +Cc: stable@vger.kernel.org +Signed-off-by: Tina Zhang +Link: https://lore.kernel.org/r/20221115070346.1112273-1-tina.zhang@intel.com +Signed-off-by: Lu Baolu +Link: https://lore.kernel.org/r/20221116051544.26540-3-baolu.lu@linux.intel.com +Signed-off-by: Joerg Roedel +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iommu/intel/pasid.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +--- a/drivers/iommu/intel/pasid.c ++++ b/drivers/iommu/intel/pasid.c +@@ -652,7 +652,7 @@ int intel_pasid_setup_second_level(struc + * Since it is a second level only translation setup, we should + * set SRE bit as well (addresses are expected to be GPAs). + */ +- if (pasid != PASID_RID2PASID) ++ if (pasid != PASID_RID2PASID && ecap_srs(iommu->ecap)) + pasid_set_sre(pte); + pasid_set_present(pte); + spin_unlock(&iommu->lock); +@@ -695,7 +695,8 @@ int intel_pasid_setup_pass_through(struc + * We should set SRE bit as well since the addresses are expected + * to be GPAs. + */ +- pasid_set_sre(pte); ++ if (ecap_srs(iommu->ecap)) ++ pasid_set_sre(pte); + pasid_set_present(pte); + spin_unlock(&iommu->lock); + diff --git a/queue-6.0/misc-vmw_vmci-fix-an-infoleak-in-vmci_host_do_receive_datagram.patch b/queue-6.0/misc-vmw_vmci-fix-an-infoleak-in-vmci_host_do_receive_datagram.patch new file mode 100644 index 00000000000..6d776da72f1 --- /dev/null +++ b/queue-6.0/misc-vmw_vmci-fix-an-infoleak-in-vmci_host_do_receive_datagram.patch @@ -0,0 +1,77 @@ +From e5b0d06d9b10f5f43101bd6598b076c347f9295f Mon Sep 17 00:00:00 2001 +From: Alexander Potapenko +Date: Fri, 4 Nov 2022 18:58:49 +0100 +Subject: misc/vmw_vmci: fix an infoleak in vmci_host_do_receive_datagram() + +From: Alexander Potapenko + +commit e5b0d06d9b10f5f43101bd6598b076c347f9295f upstream. + +`struct vmci_event_qp` allocated by qp_notify_peer() contains padding, +which may carry uninitialized data to the userspace, as observed by +KMSAN: + + BUG: KMSAN: kernel-infoleak in instrument_copy_to_user ./include/linux/instrumented.h:121 + instrument_copy_to_user ./include/linux/instrumented.h:121 + _copy_to_user+0x5f/0xb0 lib/usercopy.c:33 + copy_to_user ./include/linux/uaccess.h:169 + vmci_host_do_receive_datagram drivers/misc/vmw_vmci/vmci_host.c:431 + vmci_host_unlocked_ioctl+0x33d/0x43d0 drivers/misc/vmw_vmci/vmci_host.c:925 + vfs_ioctl fs/ioctl.c:51 + ... + + Uninit was stored to memory at: + kmemdup+0x74/0xb0 mm/util.c:131 + dg_dispatch_as_host drivers/misc/vmw_vmci/vmci_datagram.c:271 + vmci_datagram_dispatch+0x4f8/0xfc0 drivers/misc/vmw_vmci/vmci_datagram.c:339 + qp_notify_peer+0x19a/0x290 drivers/misc/vmw_vmci/vmci_queue_pair.c:1479 + qp_broker_attach drivers/misc/vmw_vmci/vmci_queue_pair.c:1662 + qp_broker_alloc+0x2977/0x2f30 drivers/misc/vmw_vmci/vmci_queue_pair.c:1750 + vmci_qp_broker_alloc+0x96/0xd0 drivers/misc/vmw_vmci/vmci_queue_pair.c:1940 + vmci_host_do_alloc_queuepair drivers/misc/vmw_vmci/vmci_host.c:488 + vmci_host_unlocked_ioctl+0x24fd/0x43d0 drivers/misc/vmw_vmci/vmci_host.c:927 + ... + + Local variable ev created at: + qp_notify_peer+0x54/0x290 drivers/misc/vmw_vmci/vmci_queue_pair.c:1456 + qp_broker_attach drivers/misc/vmw_vmci/vmci_queue_pair.c:1662 + qp_broker_alloc+0x2977/0x2f30 drivers/misc/vmw_vmci/vmci_queue_pair.c:1750 + + Bytes 28-31 of 48 are uninitialized + Memory access of size 48 starts at ffff888035155e00 + Data copied to user address 0000000020000100 + +Use memset() to prevent the infoleaks. + +Also speculatively fix qp_notify_peer_local(), which may suffer from the +same problem. + +Reported-by: syzbot+39be4da489ed2493ba25@syzkaller.appspotmail.com +Cc: stable +Fixes: 06164d2b72aa ("VMCI: queue pairs implementation.") +Signed-off-by: Alexander Potapenko +Reviewed-by: Vishnu Dasa +Link: https://lore.kernel.org/r/20221104175849.2782567-1-glider@google.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/misc/vmw_vmci/vmci_queue_pair.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/misc/vmw_vmci/vmci_queue_pair.c ++++ b/drivers/misc/vmw_vmci/vmci_queue_pair.c +@@ -854,6 +854,7 @@ static int qp_notify_peer_local(bool att + u32 context_id = vmci_get_context_id(); + struct vmci_event_qp ev; + ++ memset(&ev, 0, sizeof(ev)); + ev.msg.hdr.dst = vmci_make_handle(context_id, VMCI_EVENT_HANDLER); + ev.msg.hdr.src = vmci_make_handle(VMCI_HYPERVISOR_CONTEXT_ID, + VMCI_CONTEXT_RESOURCE_ID); +@@ -1467,6 +1468,7 @@ static int qp_notify_peer(bool attach, + * kernel. + */ + ++ memset(&ev, 0, sizeof(ev)); + ev.msg.hdr.dst = vmci_make_handle(peer_id, VMCI_EVENT_HANDLER); + ev.msg.hdr.src = vmci_make_handle(VMCI_HYPERVISOR_CONTEXT_ID, + VMCI_CONTEXT_RESOURCE_ID); diff --git a/queue-6.0/mmc-core-properly-select-voltage-range-without-power-cycle.patch b/queue-6.0/mmc-core-properly-select-voltage-range-without-power-cycle.patch new file mode 100644 index 00000000000..9f5a1aee84e --- /dev/null +++ b/queue-6.0/mmc-core-properly-select-voltage-range-without-power-cycle.patch @@ -0,0 +1,47 @@ +From 39a72dbfe188291b156dd6523511e3d5761ce775 Mon Sep 17 00:00:00 2001 +From: Yann Gautier +Date: Fri, 28 Oct 2022 09:37:40 +0200 +Subject: mmc: core: properly select voltage range without power cycle + +From: Yann Gautier + +commit 39a72dbfe188291b156dd6523511e3d5761ce775 upstream. + +In mmc_select_voltage(), if there is no full power cycle, the voltage +range selected at the end of the function will be on a single range +(e.g. 3.3V/3.4V). To keep a range around the selected voltage (3.2V/3.4V), +the mask shift should be reduced by 1. + +This issue was triggered by using a specific SD-card (Verbatim Premium +16GB UHS-1) on an STM32MP157C-DK2 board. This board cannot do UHS modes +and there is no power cycle. And the card was failing to switch to +high-speed mode. When adding the range 3.2V/3.3V for this card with the +proposed shift change, the card can switch to high-speed mode. + +Fixes: ce69d37b7d8f ("mmc: core: Prevent violation of specs while initializing cards") +Signed-off-by: Yann Gautier +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20221028073740.7259-1-yann.gautier@foss.st.com +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mmc/core/core.c | 8 +++++++- + 1 file changed, 7 insertions(+), 1 deletion(-) + +--- a/drivers/mmc/core/core.c ++++ b/drivers/mmc/core/core.c +@@ -1134,7 +1134,13 @@ u32 mmc_select_voltage(struct mmc_host * + mmc_power_cycle(host, ocr); + } else { + bit = fls(ocr) - 1; +- ocr &= 3 << bit; ++ /* ++ * The bit variable represents the highest voltage bit set in ++ * the OCR register. ++ * To keep a range of 2 values (e.g. 3.2V/3.3V and 3.3V/3.4V), ++ * we must shift the mask '3' with (bit - 1). ++ */ ++ ocr &= 3 << (bit - 1); + if (bit != host->ios.vdd) + dev_warn(mmc_dev(host), "exceeding card's volts\n"); + } diff --git a/queue-6.0/mmc-sdhci-pci-fix-possible-memory-leak-caused-by-missing-pci_dev_put.patch b/queue-6.0/mmc-sdhci-pci-fix-possible-memory-leak-caused-by-missing-pci_dev_put.patch new file mode 100644 index 00000000000..dced8427a10 --- /dev/null +++ b/queue-6.0/mmc-sdhci-pci-fix-possible-memory-leak-caused-by-missing-pci_dev_put.patch @@ -0,0 +1,36 @@ +From 222cfa0118aa68687ace74aab8fdf77ce8fbd7e6 Mon Sep 17 00:00:00 2001 +From: Xiongfeng Wang +Date: Mon, 14 Nov 2022 16:31:00 +0800 +Subject: mmc: sdhci-pci: Fix possible memory leak caused by missing pci_dev_put() + +From: Xiongfeng Wang + +commit 222cfa0118aa68687ace74aab8fdf77ce8fbd7e6 upstream. + +pci_get_device() will increase the reference count for the returned +pci_dev. We need to use pci_dev_put() to decrease the reference count +before amd_probe() returns. There is no problem for the 'smbus_dev == +NULL' branch because pci_dev_put() can also handle the NULL input +parameter case. + +Fixes: 659c9bc114a8 ("mmc: sdhci-pci: Build o2micro support in the same module") +Signed-off-by: Xiongfeng Wang +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20221114083100.149200-1-wangxiongfeng2@huawei.com +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mmc/host/sdhci-pci-core.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/mmc/host/sdhci-pci-core.c ++++ b/drivers/mmc/host/sdhci-pci-core.c +@@ -1728,6 +1728,8 @@ static int amd_probe(struct sdhci_pci_ch + } + } + ++ pci_dev_put(smbus_dev); ++ + if (gen == AMD_CHIPSET_BEFORE_ML || gen == AMD_CHIPSET_CZ) + chip->quirks2 |= SDHCI_QUIRK2_CLEAR_TRANSFERMODE_REG_BEFORE_CMD; + diff --git a/queue-6.0/mmc-sdhci-pci-o2micro-fix-card-detect-fail-issue-caused-by-cd-debounce-timeout.patch b/queue-6.0/mmc-sdhci-pci-o2micro-fix-card-detect-fail-issue-caused-by-cd-debounce-timeout.patch new file mode 100644 index 00000000000..9244df1623e --- /dev/null +++ b/queue-6.0/mmc-sdhci-pci-o2micro-fix-card-detect-fail-issue-caused-by-cd-debounce-timeout.patch @@ -0,0 +1,45 @@ +From 096cc0cddf58232bded309336961784f1d1c85f8 Mon Sep 17 00:00:00 2001 +From: Chevron Li +Date: Fri, 4 Nov 2022 02:55:12 -0700 +Subject: mmc: sdhci-pci-o2micro: fix card detect fail issue caused by CD# debounce timeout + +From: Chevron Li + +commit 096cc0cddf58232bded309336961784f1d1c85f8 upstream. + +The SD card is recognized failed sometimes when resume from suspend. +Because CD# debounce time too long then card present report wrong. +Finally, card is recognized failed. + +Signed-off-by: Chevron Li +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20221104095512.4068-1-chevron.li@bayhubtech.com +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mmc/host/sdhci-pci-o2micro.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +--- a/drivers/mmc/host/sdhci-pci-o2micro.c ++++ b/drivers/mmc/host/sdhci-pci-o2micro.c +@@ -32,6 +32,7 @@ + #define O2_SD_CAPS 0xE0 + #define O2_SD_ADMA1 0xE2 + #define O2_SD_ADMA2 0xE7 ++#define O2_SD_MISC_CTRL2 0xF0 + #define O2_SD_INF_MOD 0xF1 + #define O2_SD_MISC_CTRL4 0xFC + #define O2_SD_MISC_CTRL 0x1C0 +@@ -874,6 +875,12 @@ static int sdhci_pci_o2_probe(struct sdh + /* Set Tuning Windows to 5 */ + pci_write_config_byte(chip->pdev, + O2_SD_TUNING_CTRL, 0x55); ++ //Adjust 1st and 2nd CD debounce time ++ pci_read_config_dword(chip->pdev, O2_SD_MISC_CTRL2, &scratch_32); ++ scratch_32 &= 0xFFE7FFFF; ++ scratch_32 |= 0x00180000; ++ pci_write_config_dword(chip->pdev, O2_SD_MISC_CTRL2, scratch_32); ++ pci_write_config_dword(chip->pdev, O2_SD_DETECT_SETTING, 1); + /* Lock WP */ + ret = pci_read_config_byte(chip->pdev, + O2_SD_LOCK_WP, &scratch); diff --git a/queue-6.0/perf-x86-amd-uncore-fix-memory-leak-for-events-array.patch b/queue-6.0/perf-x86-amd-uncore-fix-memory-leak-for-events-array.patch new file mode 100644 index 00000000000..c6b8ddb15ea --- /dev/null +++ b/queue-6.0/perf-x86-amd-uncore-fix-memory-leak-for-events-array.patch @@ -0,0 +1,78 @@ +From bdfe34597139cfcecd47a2eb97fea44d77157491 Mon Sep 17 00:00:00 2001 +From: Sandipan Das +Date: Thu, 8 Sep 2022 10:33:15 +0530 +Subject: perf/x86/amd/uncore: Fix memory leak for events array + +From: Sandipan Das + +commit bdfe34597139cfcecd47a2eb97fea44d77157491 upstream. + +When a CPU comes online, the per-CPU NB and LLC uncore contexts are +freed but not the events array within the context structure. This +causes a memory leak as identified by the kmemleak detector. + + [...] + unreferenced object 0xffff8c5944b8e320 (size 32): + comm "swapper/0", pid 1, jiffies 4294670387 (age 151.072s) + hex dump (first 32 bytes): + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ + backtrace: + [<000000000759fb79>] amd_uncore_cpu_up_prepare+0xaf/0x230 + [<00000000ddc9e126>] cpuhp_invoke_callback+0x2cf/0x470 + [<0000000093e727d4>] cpuhp_issue_call+0x14d/0x170 + [<0000000045464d54>] __cpuhp_setup_state_cpuslocked+0x11e/0x330 + [<0000000069f67cbd>] __cpuhp_setup_state+0x6b/0x110 + [<0000000015365e0f>] amd_uncore_init+0x260/0x321 + [<00000000089152d2>] do_one_initcall+0x3f/0x1f0 + [<000000002d0bd18d>] kernel_init_freeable+0x1ca/0x212 + [<0000000030be8dde>] kernel_init+0x11/0x120 + [<0000000059709e59>] ret_from_fork+0x22/0x30 + unreferenced object 0xffff8c5944b8dd40 (size 64): + comm "swapper/0", pid 1, jiffies 4294670387 (age 151.072s) + hex dump (first 32 bytes): + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ + backtrace: + [<00000000306efe8b>] amd_uncore_cpu_up_prepare+0x183/0x230 + [<00000000ddc9e126>] cpuhp_invoke_callback+0x2cf/0x470 + [<0000000093e727d4>] cpuhp_issue_call+0x14d/0x170 + [<0000000045464d54>] __cpuhp_setup_state_cpuslocked+0x11e/0x330 + [<0000000069f67cbd>] __cpuhp_setup_state+0x6b/0x110 + [<0000000015365e0f>] amd_uncore_init+0x260/0x321 + [<00000000089152d2>] do_one_initcall+0x3f/0x1f0 + [<000000002d0bd18d>] kernel_init_freeable+0x1ca/0x212 + [<0000000030be8dde>] kernel_init+0x11/0x120 + [<0000000059709e59>] ret_from_fork+0x22/0x30 + [...] + +Fix the problem by freeing the events array before freeing the uncore +context. + +Fixes: 39621c5808f5 ("perf/x86/amd/uncore: Use dynamic events array") +Reported-by: Ravi Bangoria +Signed-off-by: Sandipan Das +Signed-off-by: Borislav Petkov +Tested-by: Ravi Bangoria +Cc: +Link: https://lore.kernel.org/r/4fa9e5ac6d6e41fa889101e7af7e6ba372cfea52.1662613255.git.sandipan.das@amd.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/events/amd/uncore.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/arch/x86/events/amd/uncore.c b/arch/x86/events/amd/uncore.c +index d568afc705d2..83f15fe411b3 100644 +--- a/arch/x86/events/amd/uncore.c ++++ b/arch/x86/events/amd/uncore.c +@@ -553,6 +553,7 @@ static void uncore_clean_online(void) + + hlist_for_each_entry_safe(uncore, n, &uncore_unused_list, node) { + hlist_del(&uncore->node); ++ kfree(uncore->events); + kfree(uncore); + } + } +-- +2.38.1 + diff --git a/queue-6.0/perf-x86-intel-pt-fix-sampling-using-single-range-output.patch b/queue-6.0/perf-x86-intel-pt-fix-sampling-using-single-range-output.patch new file mode 100644 index 00000000000..13dfdca4abc --- /dev/null +++ b/queue-6.0/perf-x86-intel-pt-fix-sampling-using-single-range-output.patch @@ -0,0 +1,41 @@ +From ce0d998be9274dd3a3d971cbeaa6fe28fd2c3062 Mon Sep 17 00:00:00 2001 +From: Adrian Hunter +Date: Sat, 12 Nov 2022 17:15:08 +0200 +Subject: perf/x86/intel/pt: Fix sampling using single range output + +From: Adrian Hunter + +commit ce0d998be9274dd3a3d971cbeaa6fe28fd2c3062 upstream. + +Deal with errata TGL052, ADL037 and RPL017 "Trace May Contain Incorrect +Data When Configured With Single Range Output Larger Than 4KB" by +disabling single range output whenever larger than 4KB. + +Fixes: 670638477aed ("perf/x86/intel/pt: Opportunistically use single range output mode") +Signed-off-by: Adrian Hunter +Signed-off-by: Peter Zijlstra (Intel) +Cc: stable@vger.kernel.org +Link: https://lkml.kernel.org/r/20221112151508.13768-1-adrian.hunter@intel.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/events/intel/pt.c | 9 +++++++++ + 1 file changed, 9 insertions(+) + +--- a/arch/x86/events/intel/pt.c ++++ b/arch/x86/events/intel/pt.c +@@ -1263,6 +1263,15 @@ static int pt_buffer_try_single(struct p + if (1 << order != nr_pages) + goto out; + ++ /* ++ * Some processors cannot always support single range for more than ++ * 4KB - refer errata TGL052, ADL037 and RPL017. Future processors might ++ * also be affected, so for now rather than trying to keep track of ++ * which ones, just disable it for all. ++ */ ++ if (nr_pages > 1) ++ goto out; ++ + buf->single = true; + buf->nr_pages = nr_pages; + ret = 0; diff --git a/queue-6.0/s390-dcssblk-fix-deadlock-when-adding-a-dcss.patch b/queue-6.0/s390-dcssblk-fix-deadlock-when-adding-a-dcss.patch new file mode 100644 index 00000000000..1edbec125c7 --- /dev/null +++ b/queue-6.0/s390-dcssblk-fix-deadlock-when-adding-a-dcss.patch @@ -0,0 +1,47 @@ +From a41a11b4009580edb6e2b4c76e5e2ee303f87157 Mon Sep 17 00:00:00 2001 +From: Gerald Schaefer +Date: Thu, 27 Oct 2022 16:19:38 +0200 +Subject: s390/dcssblk: fix deadlock when adding a DCSS + +From: Gerald Schaefer + +commit a41a11b4009580edb6e2b4c76e5e2ee303f87157 upstream. + +After the rework from commit 1ebe2e5f9d68 ("block: remove +GENHD_FL_EXT_DEVT"), when calling device_add_disk(), dcssblk will end up +in disk_scan_partitions(), and not break out early w/o GENHD_FL_NO_PART. +This will trigger implicit open/release via blkdev_get/put_whole() +later. dcssblk_release() will then deadlock on dcssblk_devices_sem +semaphore, which is already held from dcssblk_add_store() when calling +device_add_disk(). + +dcssblk does not support partitions (DCSSBLK_MINORS_PER_DISK == 1), and +never scanned partitions before. Therefore restore the previous +behavior, and explicitly disallow partition scanning by setting the +GENHD_FL_NO_PART flag. This will also prevent this deadlock scenario. + +Fixes: 1ebe2e5f9d68 ("block: remove GENHD_FL_EXT_DEVT") +Cc: # 5.17+ +Signed-off-by: Gerald Schaefer +Acked-by: Heiko Carstens +Signed-off-by: Alexander Gordeev +Signed-off-by: Greg Kroah-Hartman +--- + drivers/s390/block/dcssblk.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/drivers/s390/block/dcssblk.c b/drivers/s390/block/dcssblk.c +index 93b80da60277..b392b9f5482e 100644 +--- a/drivers/s390/block/dcssblk.c ++++ b/drivers/s390/block/dcssblk.c +@@ -636,6 +636,7 @@ dcssblk_add_store(struct device *dev, struct device_attribute *attr, const char + dev_info->gd->minors = DCSSBLK_MINORS_PER_DISK; + dev_info->gd->fops = &dcssblk_devops; + dev_info->gd->private_data = dev_info; ++ dev_info->gd->flags |= GENHD_FL_NO_PART; + blk_queue_logical_block_size(dev_info->gd->queue, 4096); + blk_queue_flag_set(QUEUE_FLAG_DAX, dev_info->gd->queue); + +-- +2.38.1 + diff --git a/queue-6.0/series b/queue-6.0/series index 3925e0f5c78..47191d82caa 100644 --- a/queue-6.0/series +++ b/queue-6.0/series @@ -263,3 +263,18 @@ input-iforce-invert-valid-length-check-when-fetching-device-ids.patch maccess-fix-writing-offset-in-case-of-fault-in-strncpy_from_kernel_nofault.patch net-phy-marvell-add-sleep-time-after-enabling-the-loopback-bit.patch scsi-zfcp-fix-double-free-of-fsf-request-when-qdio-send-fails.patch +iommu-vt-d-preset-access-bit-for-iova-in-fl-non-leaf-paging-entries.patch +iommu-vt-d-set-sre-bit-only-when-hardware-has-srs-cap.patch +firmware-coreboot-register-bus-in-module-init.patch +mmc-core-properly-select-voltage-range-without-power-cycle.patch +mmc-sdhci-pci-o2micro-fix-card-detect-fail-issue-caused-by-cd-debounce-timeout.patch +mmc-sdhci-pci-fix-possible-memory-leak-caused-by-missing-pci_dev_put.patch +docs-update-mediator-contact-information-in-coc-doc.patch +docs-driver-api-miscellaneous-remove-kernel-doc-of-serial_core.c.patch +s390-dcssblk-fix-deadlock-when-adding-a-dcss.patch +misc-vmw_vmci-fix-an-infoleak-in-vmci_host_do_receive_datagram.patch +blk-cgroup-properly-pin-the-parent-in-blkcg_css_online.patch +x86-sgx-add-overflow-check-in-sgx_validate_offset_length.patch +x86-fpu-drop-fpregs-lock-before-inheriting-fpu-permissions.patch +perf-x86-amd-uncore-fix-memory-leak-for-events-array.patch +perf-x86-intel-pt-fix-sampling-using-single-range-output.patch diff --git a/queue-6.0/x86-fpu-drop-fpregs-lock-before-inheriting-fpu-permissions.patch b/queue-6.0/x86-fpu-drop-fpregs-lock-before-inheriting-fpu-permissions.patch new file mode 100644 index 00000000000..0818b4ca356 --- /dev/null +++ b/queue-6.0/x86-fpu-drop-fpregs-lock-before-inheriting-fpu-permissions.patch @@ -0,0 +1,101 @@ +From 36b038791e1e2baea892e9276588815fd14894b4 Mon Sep 17 00:00:00 2001 +From: Mel Gorman +Date: Thu, 10 Nov 2022 12:44:00 +0000 +Subject: x86/fpu: Drop fpregs lock before inheriting FPU permissions + +From: Mel Gorman + +commit 36b038791e1e2baea892e9276588815fd14894b4 upstream. + +Mike Galbraith reported the following against an old fork of preempt-rt +but the same issue also applies to the current preempt-rt tree. + + BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46 + in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: systemd + preempt_count: 1, expected: 0 + RCU nest depth: 0, expected: 0 + Preemption disabled at: + fpu_clone + CPU: 6 PID: 1 Comm: systemd Tainted: G E (unreleased) + Call Trace: + + dump_stack_lvl + ? fpu_clone + __might_resched + rt_spin_lock + fpu_clone + ? copy_thread + ? copy_process + ? shmem_alloc_inode + ? kmem_cache_alloc + ? kernel_clone + ? __do_sys_clone + ? do_syscall_64 + ? __x64_sys_rt_sigprocmask + ? syscall_exit_to_user_mode + ? do_syscall_64 + ? syscall_exit_to_user_mode + ? do_syscall_64 + ? syscall_exit_to_user_mode + ? do_syscall_64 + ? exc_page_fault + ? entry_SYSCALL_64_after_hwframe + + +Mike says: + + The splat comes from fpu_inherit_perms() being called under fpregs_lock(), + and us reaching the spin_lock_irq() therein due to fpu_state_size_dynamic() + returning true despite static key __fpu_state_size_dynamic having never + been enabled. + +Mike's assessment looks correct. fpregs_lock on a PREEMPT_RT kernel disables +preemption so calling spin_lock_irq() in fpu_inherit_perms() is unsafe. This +problem exists since commit + + 9e798e9aa14c ("x86/fpu: Prepare fpu_clone() for dynamically enabled features"). + +Even though the original bug report should not have enabled the paths at +all, the bug still exists. + +fpregs_lock is necessary when editing the FPU registers or a task's FP +state but it is not necessary for fpu_inherit_perms(). The only write +of any FP state in fpu_inherit_perms() is for the new child which is +not running yet and cannot context switch or be borrowed by a kernel +thread yet. Hence, fpregs_lock is not protecting anything in the new +child until clone() completes and can be dropped earlier. The siglock +still needs to be acquired by fpu_inherit_perms() as the read of the +parent's permissions has to be serialised. + + [ bp: Cleanup splat. ] + +Fixes: 9e798e9aa14c ("x86/fpu: Prepare fpu_clone() for dynamically enabled features") +Reported-by: Mike Galbraith +Signed-off-by: Mel Gorman +Signed-off-by: Borislav Petkov +Reviewed-by: Thomas Gleixner +Cc: +Link: https://lore.kernel.org/r/20221110124400.zgymc2lnwqjukgfh@techsingularity.net +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/fpu/core.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c +index 3b28c5b25e12..d00db56a8868 100644 +--- a/arch/x86/kernel/fpu/core.c ++++ b/arch/x86/kernel/fpu/core.c +@@ -605,9 +605,9 @@ int fpu_clone(struct task_struct *dst, unsigned long clone_flags, bool minimal) + if (test_thread_flag(TIF_NEED_FPU_LOAD)) + fpregs_restore_userregs(); + save_fpregs_to_fpstate(dst_fpu); ++ fpregs_unlock(); + if (!(clone_flags & CLONE_THREAD)) + fpu_inherit_perms(dst_fpu); +- fpregs_unlock(); + + /* + * Children never inherit PASID state. +-- +2.38.1 + diff --git a/queue-6.0/x86-sgx-add-overflow-check-in-sgx_validate_offset_length.patch b/queue-6.0/x86-sgx-add-overflow-check-in-sgx_validate_offset_length.patch new file mode 100644 index 00000000000..11c5bb90ac8 --- /dev/null +++ b/queue-6.0/x86-sgx-add-overflow-check-in-sgx_validate_offset_length.patch @@ -0,0 +1,39 @@ +From f0861f49bd946ff94fce4f82509c45e167f63690 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Borys=20Pop=C5=82awski?= +Date: Wed, 5 Oct 2022 00:59:03 +0200 +Subject: x86/sgx: Add overflow check in sgx_validate_offset_length() +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Borys Popławski + +commit f0861f49bd946ff94fce4f82509c45e167f63690 upstream. + +sgx_validate_offset_length() function verifies "offset" and "length" +arguments provided by userspace, but was missing an overflow check on +their addition. Add it. + +Fixes: c6d26d370767 ("x86/sgx: Add SGX_IOC_ENCLAVE_ADD_PAGES") +Signed-off-by: Borys Popławski +Signed-off-by: Borislav Petkov +Reviewed-by: Jarkko Sakkinen +Cc: stable@vger.kernel.org # v5.11+ +Link: https://lore.kernel.org/r/0d91ac79-6d84-abed-5821-4dbe59fa1a38@invisiblethingslab.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/cpu/sgx/ioctl.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/arch/x86/kernel/cpu/sgx/ioctl.c ++++ b/arch/x86/kernel/cpu/sgx/ioctl.c +@@ -356,6 +356,9 @@ static int sgx_validate_offset_length(st + if (!length || !IS_ALIGNED(length, PAGE_SIZE)) + return -EINVAL; + ++ if (offset + length < offset) ++ return -EINVAL; ++ + if (offset + length - PAGE_SIZE >= encl->size) + return -EINVAL; + -- 2.47.3