Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/ https://git.shady.money/linux/atom?h=v6.0 2022-09-28T18:36:31Z 2022-09-28T18:36:31Z Linus Torvalds torvalds@linux-foundation.org 2022-09-28T18:36:31Z urn:sha1:e817c070fd9f813774defd8ef5e0349108e924e0 Pull MMC fixes from Ulf Hansson: "A couple of MMC fixes. This time there is also a fix for the ARM SCMI firmware driver, which has been acked by Sudeep Holla, the maintainer. MMC core: - Terminate infinite loop in SD-UHS voltage switch MMC host: - hsq: Fix kernel crash in the recovery path - moxart: Fix bus width configurations - sdhci: Fix kernel panic for cqe irq ARM_SCMI: - Fixup clock management by reverting 'firmware: arm_scmi: Add clock management to the SCMI power domain'" * tag 'mmc-v6.0-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc: mmc: hsq: Fix data stomping during mmc recovery Revert "firmware: arm_scmi: Add clock management to the SCMI power domain" mmc: core: Terminate infinite loop in SD-UHS voltage switch mmc: moxart: fix 4-bit bus width and remove 8-bit bus width mmc: sdhci: Fix host->cmd is null 2022-09-23T08:19:47Z Ulf Hansson ulf.hansson@linaro.org 2022-09-19T12:20:33Z urn:sha1:3c6656337852e9f1a4079d172f3fddfbf00868f9 This reverts commit a3b884cef873 ("firmware: arm_scmi: Add clock management to the SCMI power domain"). Using the GENPD_FLAG_PM_CLK tells genpd to gate/ungate the consumer device's clock(s) during runtime suspend/resume through the PM clock API. More precisely, in genpd_runtime_resume() the clock(s) for the consumer device would become ungated prior to the driver-level ->runtime_resume() callbacks gets invoked. This behaviour isn't a good fit for all platforms/drivers. For example, a driver may need to make some preparations of its device in its ->runtime_resume() callback, like calling clk_set_rate() before the clock(s) should be ungated. In these cases, it's easier to let the clock(s) to be managed solely by the driver, rather than at the PM domain level. For these reasons, let's drop the use GENPD_FLAG_PM_CLK for the SCMI PM domain, as to enable it to be more easily adopted across ARM platforms. Fixes: a3b884cef873 ("firmware: arm_scmi: Add clock management to the SCMI power domain") Cc: Nicolas Pitre <npitre@baylibre.com> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Tested-by: Peng Fan <peng.fan@nxp.com> Acked-by: Sudeep Holla <sudeep.holla@arm.com> Link: https://lore.kernel.org/r/20220919122033.86126-1-ulf.hansson@linaro.org 2022-09-22T18:10:11Z Linus Torvalds torvalds@linux-foundation.org 2022-09-22T18:10:11Z urn:sha1:c69cf88cda5faca0e411babb67ac0d8bfd8b4646 Pull ARM SoC fixes from Arnd Bergmann: "Another set of fixes for fixes for the soc tree: - A fix for the interrupt number on at91/lan966 ethernet PHYs - A second round of fixes for NXP i.MX series, including a couple of build issues, and board specific DT corrections on TQMa8MPQL, imx8mp-venice-gw74xx and imx8mm-verdin for reliability and partially broken functionality - Several fixes for Rockchip SoCs, addressing a USB issue on BPI-R2-Pro, wakeup on Gru-Bob and reliability of high-speed SD cards, among other minor issues - A fix for a long-running naming mistake that prevented the moxart mmc driver from working at all - Multiple Arm SCMI firmware fixes for hardening some corner cases" * tag 'soc-fixes-6.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (30 commits) arm64: dts: imx8mp-venice-gw74xx: fix port/phy validation ARM: dts: lan966x: Fix the interrupt number for internal PHYs arm64: dts: imx8mp-venice-gw74xx: fix ksz9477 cpu port arm64: dts: imx8mp-venice-gw74xx: fix CAN STBY polarity dt-bindings: memory-controllers: fsl,imx8m-ddrc: drop Leonard Crestez arm64: dts: tqma8mqml: Include phy-imx8-pcie.h header arm64: defconfig: enable ARCH_NXP arm64: dts: imx8mp-tqma8mpql-mba8mpxl: add missing pinctrl for RTC alarm ARM: dts: fix Moxa SDIO 'compatible', remove 'sdhci' misnomer arm64: dts: imx8mm-verdin: extend pmic voltages arm64: dts: rockchip: Remove 'enable-active-low' from rk3566-quartz64-a arm64: dts: rockchip: Remove 'enable-active-low' from rk3399-puma arm64: dts: rockchip: fix property for usb2 phy supply on rk3568-evb1-v10 arm64: dts: rockchip: fix property for usb2 phy supply on rock-3a arm64: dts: imx8ulp: add #reset-cells for pcc arm64: dts: tqma8mpxl-ba8mpxl: Fix button GPIOs arm64: dts: imx8mn: remove GPU power domain reset arm64: dts: rockchip: Set RK3399-Gru PCLK_EDP to 24 MHz arm64: dts: imx8mm: Reverse CPLD_Dn GPIO label mapping on MX8Menlo arm64: dts: rockchip: fix upper usb port on BPI-R2-Pro ... 2022-09-22T17:27:38Z Linus Torvalds torvalds@linux-foundation.org 2022-09-22T17:27:38Z urn:sha1:129e7152184b0224f9ca3f91b870acc14c64e1fa Pull EFI fixes from Ard Biesheuvel: - Use the right variable to check for shim insecure mode - Wipe setup_data field when booting via EFI - Add missing error check to efibc driver * tag 'efi-urgent-for-v6.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi: efi: libstub: check Shim mode using MokSBStateRT efi: x86: Wipe setup_data on pure EFI boot efi: efibc: Guard against allocation failure 2022-09-22T08:15:44Z Ard Biesheuvel ardb@kernel.org 2022-09-20T15:08:23Z urn:sha1:5f56a74cc0a6d9b9f8ba89cea29cd7c4774cb2b1 We currently check the MokSBState variable to decide whether we should treat UEFI secure boot as being disabled, even if the firmware thinks otherwise. This is used by shim to indicate that it is not checking signatures on boot images. In the kernel, we use this to relax lockdown policies. However, in cases where shim is not even being used, we don't want this variable to interfere with lockdown, given that the variable may be non-volatile and therefore persist across a reboot. This means setting it once will persistently disable lockdown checks on a given system. So switch to the mirrored version of this variable, called MokSBStateRT, which is supposed to be volatile, and this is something we can check. Cc: <stable@vger.kernel.org> # v4.19+ Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Peter Jones <pjones@redhat.com> 2022-09-22T08:12:51Z Ard Biesheuvel ardb@kernel.org 2022-08-04T13:39:48Z urn:sha1:63bf28ceb3ebbe76048c3fb2987996ca1ae64f83 When booting the x86 kernel via EFI using the LoadImage/StartImage boot services [as opposed to the deprecated EFI handover protocol], the setup header is taken from the image directly, and given that EFI's LoadImage has no Linux/x86 specific knowledge regarding struct bootparams or struct setup_header, any absolute addresses in the setup header must originate from the file and not from a prior loading stage. Since we cannot generally predict where LoadImage() decides to load an image (*), such absolute addresses must be treated as suspect: even if a prior boot stage intended to make them point somewhere inside the [signed] image, there is no way to validate that, and if they point at an arbitrary location in memory, the setup_data nodes will not be covered by any signatures or TPM measurements either, and could be made to contain an arbitrary sequence of SETUP_xxx nodes, which could interfere quite badly with the early x86 boot sequence. (*) Note that, while LoadImage() does take a buffer/size tuple in addition to a device path, which can be used to provide the image contents directly, it will re-allocate such images, as the memory footprint of an image is generally larger than the PE/COFF file representation. Cc: <stable@vger.kernel.org> # v5.10+ Link: https://lore.kernel.org/all/20220904165321.1140894-1-Jason@zx2c4.com/ Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Jason A. Donenfeld <Jason@zx2c4.com> 2022-09-20T16:42:55Z Guilherme G. Piccoli gpiccoli@igalia.com 2022-09-09T19:42:14Z urn:sha1:7da5b13dccd99cfdc42940fc7adcb88647023292 There is a single kmalloc in this driver, and it's not currently guarded against allocation failure. Do it here by just bailing-out the reboot handler, in case this tentative allocation fails. Fixes: 416581e48679 ("efi: efibc: avoid efivar API for setting variables") Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> 2022-09-08T14:12:26Z Arnd Bergmann arnd@arndb.de 2022-09-08T14:12:25Z urn:sha1:d4f1920d07e8eb0f217f8f65c0bc5b20bb8e3b8c Arm SCMI fixes for v6.0 Few fixes addressing possible out of bound access violations by hardening them, incorrect asynchronous resets by restricting them, incorrect SCMI tracing message format by harmonizing them, missing kernel-doc in optee transport, missing SCMI PM driver remove routine by adding it to avoid warning when scmi driver is unloaded and finally improve checks in the info_get operations. * tag 'scmi-fixes-6.0' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: firmware: arm_scmi: Harmonize SCMI tracing message format firmware: arm_scmi: Add SCMI PM driver remove routine firmware: arm_scmi: Fix the asynchronous reset requests firmware: arm_scmi: Harden accesses to the reset domains firmware: arm_scmi: Harden accesses to the sensor domains firmware: arm_scmi: Improve checks in the info_get operations firmware: arm_scmi: Fix missing kernel-doc in optee Link: https://lore.kernel.org/r/20220829174435.207911-1-sudeep.holla@arm.com Signed-off-by: Arnd Bergmann <arnd@arndb.de> 2022-09-08T11:37:38Z Linus Torvalds torvalds@linux-foundation.org 2022-09-08T11:37:38Z urn:sha1:f280b9872af1f58760b7731e973de57ffccfb0a4 Pull EFI fixes from Ard Biesheuvel: "A couple of low-priority EFI fixes: - prevent the randstruct plugin from re-ordering EFI protocol definitions - fix a use-after-free in the capsule loader - drop unused variable" * tag 'efi-urgent-for-v6.0-1' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi: efi: capsule-loader: Fix use-after-free in efi_capsule_write efi/x86: libstub: remove unused variable efi: libstub: Disable struct randomization 2022-09-07T16:23:56Z Hyunwoo Kim imv4bel@gmail.com 2022-09-07T16:07:14Z urn:sha1:9cb636b5f6a8cc6d1b50809ec8f8d33ae0c84c95 A race condition may occur if the user calls close() on another thread during a write() operation on the device node of the efi capsule. This is a race condition that occurs between the efi_capsule_write() and efi_capsule_flush() functions of efi_capsule_fops, which ultimately results in UAF. So, the page freeing process is modified to be done in efi_capsule_release() instead of efi_capsule_flush(). Cc: <stable@vger.kernel.org> # v4.9+ Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com> Link: https://lore.kernel.org/all/20220907102920.GA88602@ubuntu/ Signed-off-by: Ard Biesheuvel <ardb@kernel.org>