October 2021 - Linux-stable-mirror

by Greg Kroah-Hartman

I'm announcing the release of the 5.14.11 kernel. All users of the 5.14 kernel series must upgrade. The updated 5.14.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-5.14.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h ------------ Makefile | 2 arch/arm/mach-imx/mach-imx6q.c | 3 arch/sparc/lib/iomap.c | 2 arch/x86/events/core.c | 1 arch/x86/kvm/svm/svm.c | 2 arch/x86/kvm/x86.c | 14 + arch/x86/lib/insn.c | 4 block/bio.c | 2 drivers/ata/libata-core.c | 34 +++ drivers/gpu/drm/amd/amdkfd/kfd_device.c | 1 drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 16 - drivers/gpu/drm/amd/amdkfd/kfd_migrate.h | 5 drivers/irqchip/irq-gic.c | 52 +++++ drivers/misc/habanalabs/common/command_submission.c | 9 drivers/misc/habanalabs/gaudi/gaudi.c | 9 drivers/misc/habanalabs/gaudi/gaudi_security.c | 115 ++++++------ drivers/misc/habanalabs/include/gaudi/asic_reg/gaudi_regs.h | 2 drivers/net/phy/mdio_device.c | 11 + drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 17 - drivers/net/xen-netback/netback.c | 2 drivers/nvme/host/fc.c | 18 + drivers/platform/x86/gigabyte-wmi.c | 1 drivers/platform/x86/touchscreen_dmi.c | 54 +++++ drivers/scsi/elx/efct/efct_lio.c | 4 drivers/scsi/sd.c | 9 drivers/scsi/ses.c | 22 +- drivers/spi/spi-rockchip.c | 6 drivers/thermal/qcom/tsens.c | 4 drivers/usb/dwc2/hcd.c | 4 drivers/xen/gntdev.c | 8 drivers/xen/swiotlb-xen.c | 7 fs/afs/dir.c | 11 + fs/afs/file.c | 16 + fs/afs/write.c | 17 + fs/btrfs/file-item.c | 13 + fs/btrfs/volumes.c | 13 + fs/cifs/smb2pdu.c | 4 fs/ext2/balloc.c | 14 - fs/io_uring.c | 8 fs/nfsd/nfs4state.c | 16 + include/linux/libata.h | 1 include/linux/mdio.h | 3 scripts/Makefile.kasan | 3 tools/arch/x86/lib/insn.c | 4 tools/testing/selftests/kvm/include/test_util.h | 3 tools/testing/selftests/kvm/lib/test_util.c | 22 ++ tools/testing/selftests/kvm/steal_time.c | 20 -- tools/testing/selftests/kvm/x86_64/mmio_warning_test.c | 3 tools/testing/selftests/kvm/x86_64/xen_shinfo_test.c | 15 - tools/testing/selftests/lib.mk | 1 tools/usb/testusb.c | 14 - tools/vm/page-types.c | 2 virt/kvm/kvm_main.c | 6 53 files changed, 472 insertions(+), 177 deletions(-) Anand K Mistry (1): perf/x86: Reset destroy callback on event init failure Ansuel Smith (1): thermal/drivers/tsens: Fix wrong check for tzd in irq handlers Changbin Du (1): tools/vm/page-types: remove dependency on opt_file for idle page tracking Dai Ngo (1): nfsd: back channel stuck in SEQ4_STATUS_CB_PATH_DOWN Dan Carpenter (1): ext2: fix sleeping in atomic bugs on error Daniel Wagner (1): nvme-fc: update hardware queues before using them David Howells (1): afs: Add missing vnode validation checks Fabio Estevam (1): Revert "ARM: imx6q: drop of_platform_default_populate() from init_machine" Faizel K B (1): usb: testusb: Fix for showing the connection speed Fares Mehanna (1): kvm: x86: Add AMD PMU MSRs to msrs_to_save_all[] Filipe Manana (1): btrfs: fix mount failure due to past and transient device flush error Greg Kroah-Hartman (1): Linux 5.14.11 Hans de Goede (2): platform/x86: touchscreen_dmi: Add info for the Chuwi HiBook (CWI514) tablet platform/x86: touchscreen_dmi: Update info for the Chuwi Hi10 Plus (CWI527) tablet James Smart (2): scsi: elx: efct: Do not hold lock while calling fc_vport_terminate() nvme-fc: avoid race between time out and tear down Jan Beulich (3): xen-netback: correct success/error reporting for the SKB-with-fraglist case Xen/gntdev: don't ignore kernel unmapping error swiotlb-xen: ensure to issue well-formed XENMEM_exchange requests Jens Axboe (1): io_uring: allow conditional reschedule for intensive iterators Kate Hsuan (1): libata: Add ATA_HORKAGE_NO_NCQ_ON_ATI for Samsung 860 and 870 SSD. Li Zhijian (1): selftests: be sure to make khdr before other targets Linus Torvalds (1): sparc64: fix pci_iounmap() when CONFIG_PCI is not set Marc Zyngier (1): irqchip/gic: Work around broken Renesas integration Maxim Levitsky (2): KVM: x86: reset pdptrs_from_userspace when exiting smm KVM: x86: nSVM: restore int_vector in svm_clear_vintr Ming Lei (2): scsi: sd: Free scsi_disk device via put_device() block: don't call rq_qos_ops->done_bio if the bio isn't tracked Nathan Chancellor (1): kasan: always respect CONFIG_KASAN_STACK Numfor Mbiziwo-Tiapo (1): x86/insn, tools/x86: Fix undefined behavior due to potential unaligned accesses Oded Gabbay (1): habanalabs/gaudi: fix LBW RR configuration Ofir Bitton (1): habanalabs: fail collective wait when not supported Oliver Upton (1): selftests: KVM: Align SMCCC call with the spec in steal_time Omer Shpigelman (1): habanalabs/gaudi: use direct MSI in single mode Philip Yang (2): drm/amdkfd: handle svm migrate init error drm/amdkfd: fix svm_migrate_fini warning Qu Wenruo (1): btrfs: replace BUG_ON() in btrfs_csum_one_bio() with proper error handling Sergey Senozhatsky (1): KVM: do not shrink halt_poll_ns below grow_start Shuah Khan (4): selftests:kvm: fix get_warnings_count() ignoring fscanf() return warn selftests:kvm: fix get_trans_hugepagesz() ignoring fscanf() return warn selftests: kvm: move get_run_delay() into lib/test_util selftests: kvm: fix get_run_delay() ignoring fscanf() return warn Soeren Moch (1): Revert "brcmfmac: use ISO3166 country code and 0 rev as fallback" Steve French (1): smb3: correct smb3 ACL security descriptor Tobias Jakobi (1): platform/x86: gigabyte-wmi: add support for B550I Aorus Pro AX Tobias Schramm (1): spi: rockchip: handle zero length transfers without timing out Vladimir Oltean (1): net: mdio: introduce a shutdown method to mdio device drivers Wen Xiong (1): scsi: ses: Retry failed Send/Receive Diagnostic commands Yang Yingliang (1): usb: dwc2: check return value after calling platform_get_resource()

3 years, 2 months

3
3
0 0

pmu-events/jevents.c:1188:9: warning: implicit declaration of function 'free_sys_event_tables' [-Wimplicit-function-declaration]

by Naresh Kamboju

stable-rc 5.10 perf build failed due to these warnings / errors. metadata: git_describe: v5.10.72-85-g431c7c55f183 git_repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git_short_log: 431c7c55f183 (\"Linux 5.10.73-rc1\") target_arch: x86_64 toolchain: gcc-11 pmu-events/jevents.c: In function 'main': pmu-events/jevents.c:1188:9: warning: implicit declaration of function 'free_sys_event_tables' [-Wimplicit-function-declaration] 1188 | free_sys_event_tables(); | ^~~~~~~~~~~~~~~~~~~~~ /usr/bin/ld: /home/tuxbuild/.cache/tuxmake/builds/current/pmu-events/jevents-in.o: in function `main': (.text+0x469e): undefined reference to `free_sys_event_tables' /usr/bin/ld: (.text+0x475e): undefined reference to `free_sys_event_tables' collect2: error: ld returned 1 exit status make[2]: *** [Makefile.perf:649: /home/tuxbuild/.cache/tuxmake/builds/current/pmu-events/jevents] Error 1 make[2]: *** Waiting for unfinished jobs.... LINK /home/tuxbuild/.cache/tuxmake/builds/current/plugin_cfg80211.so GEN /home/tuxbuild/.cache/tuxmake/builds/current/libtraceevent-dynamic-list make[1]: *** [Makefile.perf:229: sub-make] Error 2 make: *** [Makefile:70: all] Error 2 Reported-by: Linux Kernel Functional Testing <lkft(a)linaro.org> build link: ----------- https://builds.tuxbuild.com/1zLv2snHfZN8QV01yA9MB8NhUZt/build.log build config: ------------- https://builds.tuxbuild.com/1zLv2snHfZN8QV01yA9MB8NhUZt/config -- Linaro LKFT https://lkft.linaro.org

3 years, 2 months

3
2
0 0

[PATCH v3 2/2] mwifiex: Try waking the firmware until we get an interrupt

by Jonas Dreßler

It seems that the PCIe+USB firmware (latest version 15.68.19.p21) of the 88W8897 card sometimes ignores or misses when we try to wake it up by writing to the firmware status register. This leads to the firmware wakeup timeout expiring and the driver resetting the card because we assume the firmware has hung up or crashed. Turns out that the firmware actually didn't hang up, but simply "missed" our wakeup request and didn't send us an interrupt with an AWAKE event. Trying again to read the firmware status register after a short timeout usually makes the firmware wake up as expected, so add a small retry loop to mwifiex_pm_wakeup_card() that looks at the interrupt status to check whether the card woke up. The number of tries and timeout lengths for this were determined experimentally: The firmware usually takes about 500 us to wake up after we attempt to read the status register. In some cases where the firmware is very busy (for example while doing a bluetooth scan) it might even miss our requests for multiple milliseconds, which is why after 15 tries the waiting time gets increased to 10 ms. The maximum number of tries it took to wake the firmware when testing this was around 20, so a maximum number of 50 tries should give us plenty of safety margin. Here's a reproducer for those firmware wakeup failures I've found: 1) Make sure wifi powersaving is enabled (iw dev wlp1s0 set power_save on) 2) Connect to any wifi network (makes firmware go into wifi powersaving mode, not deep sleep) 3) Make sure bluetooth is turned off (to ensure the firmware actually enters powersave mode and doesn't keep the radio active doing bluetooth stuff) 4) To confirm that wifi powersaving is entered ping a device on the LAN, pings should be a few ms higher than without powersaving 5) Run "while true; do iwconfig; sleep 0.0001; done", this wakes and suspends the firmware extremely often 6) Wait until things explode, for me it consistently takes <5 minutes BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=109681 Cc: stable(a)vger.kernel.org Signed-off-by: Jonas Dreßler <verdre(a)v0yd.nl> --- drivers/net/wireless/marvell/mwifiex/pcie.c | 28 +++++++++++++++++---- 1 file changed, 23 insertions(+), 5 deletions(-) diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c index 641fa539de1f..c3f5583ea70d 100644 --- a/drivers/net/wireless/marvell/mwifiex/pcie.c +++ b/drivers/net/wireless/marvell/mwifiex/pcie.c @@ -17,6 +17,7 @@ * this warranty disclaimer. */ +#include <linux/iopoll.h> #include <linux/firmware.h> #include "decl.h" @@ -647,11 +648,15 @@ static void mwifiex_delay_for_sleep_cookie(struct mwifiex_adapter *adapter, "max count reached while accessing sleep cookie\n"); } +#define N_WAKEUP_TRIES_SHORT_INTERVAL 15 +#define N_WAKEUP_TRIES_LONG_INTERVAL 35 + /* This function wakes up the card by reading fw_status register. */ static int mwifiex_pm_wakeup_card(struct mwifiex_adapter *adapter) { struct pcie_service_card *card = adapter->card; const struct mwifiex_pcie_card_reg *reg = card->pcie.reg; + int retval; mwifiex_dbg(adapter, EVENT, "event: Wakeup device...\n"); @@ -659,11 +664,24 @@ static int mwifiex_pm_wakeup_card(struct mwifiex_adapter *adapter) if (reg->sleep_cookie) mwifiex_pcie_dev_wakeup_delay(adapter); - /* Accessing fw_status register will wakeup device */ - if (mwifiex_write_reg(adapter, reg->fw_status, FIRMWARE_READY_PCIE)) { - mwifiex_dbg(adapter, ERROR, - "Writing fw_status register failed\n"); - return -1; + /* The 88W8897 PCIe+USB firmware (latest version 15.68.19.p21) sometimes + * appears to ignore or miss our wakeup request, so we continue trying + * until we receive an interrupt from the card. + */ + if (read_poll_timeout(mwifiex_write_reg, retval, + READ_ONCE(adapter->int_status) != 0, + 500, 500 * N_WAKEUP_TRIES_SHORT_INTERVAL, + false, + adapter, reg->fw_status, FIRMWARE_READY_PCIE)) { + if (read_poll_timeout(mwifiex_write_reg, retval, + READ_ONCE(adapter->int_status) != 0, + 10000, 10000 * N_WAKEUP_TRIES_LONG_INTERVAL, + false, + adapter, reg->fw_status, FIRMWARE_READY_PCIE)) { + mwifiex_dbg(adapter, ERROR, + "Firmware didn't wake up\n"); + return -EIO; + } } if (reg->sleep_cookie) { -- 2.31.1

3 years, 2 months

1
0
0 0

[PATCH backport for v5.4 and before] x86/Kconfig: Correct reference to MWINCHIP3D

by Lukas Bulwahn

commit 225bac2dc5d192e55f2c50123ee539b1edf8a411 upstream. Commit in Fixes intended to exclude the Winchip series and referred to CONFIG_WINCHIP3D, but the config symbol is called CONFIG_MWINCHIP3D. Hence, scripts/checkkconfigsymbols.py warns: WINCHIP3D Referencing files: arch/x86/Kconfig Correct the reference to the intended config symbol. Fixes: 69b8d3fcabdc ("x86/Kconfig: Exclude i586-class CPUs lacking PAE support from the HIGHMEM64G Kconfig group") Suggested-by: Randy Dunlap <rdunlap(a)infradead.org> Signed-off-by: Lukas Bulwahn <lukas.bulwahn(a)gmail.com> Signed-off-by: Borislav Petkov <bp(a)suse.de> Cc: <stable(a)vger.kernel.org> Link: https://lkml.kernel.org/r/20210803113531.30720-4-lukas.bulwahn@gmail.com [manually adjusted the change to the state on the v4.19.y and v5.4.y stable tree] Signed-off-by: Lukas Bulwahn <lukas.bulwahn(a)gmail.com> --- arch/x86/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index d994501d9179..3dd2949b2b35 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -1387,7 +1387,7 @@ config HIGHMEM4G config HIGHMEM64G bool "64GB" - depends on !M486 && !M586 && !M586TSC && !M586MMX && !MGEODE_LX && !MGEODEGX1 && !MCYRIXIII && !MELAN && !MWINCHIPC6 && !WINCHIP3D && !MK6 + depends on !M486 && !M586 && !M586TSC && !M586MMX && !MGEODE_LX && !MGEODEGX1 && !MCYRIXIII && !MELAN && !MWINCHIPC6 && !MWINCHIP3D && !MK6 select X86_PAE ---help--- Select this if you have a 32-bit processor and more than 4 -- 2.26.2

3 years, 2 months

2
1
0 0

FAILED: patch "[PATCH] x86/Kconfig: Correct reference to MWINCHIP3D" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 225bac2dc5d192e55f2c50123ee539b1edf8a411 Mon Sep 17 00:00:00 2001 From: Lukas Bulwahn <lukas.bulwahn(a)gmail.com> Date: Tue, 3 Aug 2021 13:35:25 +0200 Subject: [PATCH] x86/Kconfig: Correct reference to MWINCHIP3D Commit in Fixes intended to exclude the Winchip series and referred to CONFIG_WINCHIP3D, but the config symbol is called CONFIG_MWINCHIP3D. Hence, scripts/checkkconfigsymbols.py warns: WINCHIP3D Referencing files: arch/x86/Kconfig Correct the reference to the intended config symbol. Fixes: 69b8d3fcabdc ("x86/Kconfig: Exclude i586-class CPUs lacking PAE support from the HIGHMEM64G Kconfig group") Suggested-by: Randy Dunlap <rdunlap(a)infradead.org> Signed-off-by: Lukas Bulwahn <lukas.bulwahn(a)gmail.com> Signed-off-by: Borislav Petkov <bp(a)suse.de> Cc: <stable(a)vger.kernel.org> Link: https://lkml.kernel.org/r/20210803113531.30720-4-lukas.bulwahn@gmail.com diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index ab83c22d274e..8055da49f1c0 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -1405,7 +1405,7 @@ config HIGHMEM4G config HIGHMEM64G bool "64GB" - depends on !M486SX && !M486 && !M586 && !M586TSC && !M586MMX && !MGEODE_LX && !MGEODEGX1 && !MCYRIXIII && !MELAN && !MWINCHIPC6 && !WINCHIP3D && !MK6 + depends on !M486SX && !M486 && !M586 && !M586TSC && !M586MMX && !MGEODE_LX && !MGEODEGX1 && !MCYRIXIII && !MELAN && !MWINCHIPC6 && !MWINCHIP3D && !MK6 select X86_PAE help Select this if you have a 32-bit processor and more than 4

3 years, 2 months

2
1
0 0

FAILED: patch "[PATCH] x86/Kconfig: Correct reference to MWINCHIP3D" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 225bac2dc5d192e55f2c50123ee539b1edf8a411 Mon Sep 17 00:00:00 2001 From: Lukas Bulwahn <lukas.bulwahn(a)gmail.com> Date: Tue, 3 Aug 2021 13:35:25 +0200 Subject: [PATCH] x86/Kconfig: Correct reference to MWINCHIP3D Commit in Fixes intended to exclude the Winchip series and referred to CONFIG_WINCHIP3D, but the config symbol is called CONFIG_MWINCHIP3D. Hence, scripts/checkkconfigsymbols.py warns: WINCHIP3D Referencing files: arch/x86/Kconfig Correct the reference to the intended config symbol. Fixes: 69b8d3fcabdc ("x86/Kconfig: Exclude i586-class CPUs lacking PAE support from the HIGHMEM64G Kconfig group") Suggested-by: Randy Dunlap <rdunlap(a)infradead.org> Signed-off-by: Lukas Bulwahn <lukas.bulwahn(a)gmail.com> Signed-off-by: Borislav Petkov <bp(a)suse.de> Cc: <stable(a)vger.kernel.org> Link: https://lkml.kernel.org/r/20210803113531.30720-4-lukas.bulwahn@gmail.com diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index ab83c22d274e..8055da49f1c0 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -1405,7 +1405,7 @@ config HIGHMEM4G config HIGHMEM64G bool "64GB" - depends on !M486SX && !M486 && !M586 && !M586TSC && !M586MMX && !MGEODE_LX && !MGEODEGX1 && !MCYRIXIII && !MELAN && !MWINCHIPC6 && !WINCHIP3D && !MK6 + depends on !M486SX && !M486 && !M586 && !M586TSC && !M586MMX && !MGEODE_LX && !MGEODEGX1 && !MCYRIXIII && !MELAN && !MWINCHIPC6 && !MWINCHIP3D && !MK6 select X86_PAE help Select this if you have a 32-bit processor and more than 4

3 years, 2 months

2
1
0 0

[PATCH v2 0/2] powerpc:85xx: fix timebase sync issue when CONFIG_HOTPLUG_CPU=n

by Xiaoming Ni

When CONFIG_SMP=y, timebase synchronization is required for mpc8572 when the second kernel is started arch/powerpc/kernel/smp.c: int __cpu_up(unsigned int cpu, struct task_struct *tidle) { ... if (smp_ops->give_timebase) smp_ops->give_timebase(); ... } void start_secondary(void *unused) { ... if (smp_ops->take_timebase) smp_ops->take_timebase(); ... } When CONFIG_HOTPLUG_CPU=n and CONFIG_KEXEC_CORE=n, smp_85xx_ops.give_timebase is NULL, smp_85xx_ops.take_timebase is NULL, As a result, the timebase is not synchronized. test code: for i in $(seq 1 3); do taskset 1 date; taskset 2 date; sleep 1; echo;done log: Sat Sep 25 18:50:00 CST 2021 Sat Sep 25 19:07:47 CST 2021 Sat Sep 25 18:50:01 CST 2021 Sat Sep 25 19:07:48 CST 2021 Sat Sep 25 18:50:02 CST 2021 Sat Sep 25 19:07:49 CST 2021 Code snippet about give_timebase and take_timebase assignments: arch/powerpc/platforms/85xx/smp.c: #ifdef CONFIG_HOTPLUG_CPU #ifdef CONFIG_FSL_CORENET_RCPM fsl_rcpm_init(); #endif #ifdef CONFIG_FSL_PMC mpc85xx_setup_pmc(); #endif if (qoriq_pm_ops) { smp_85xx_ops.give_timebase = mpc85xx_give_timebase; smp_85xx_ops.take_timebase = mpc85xx_take_timebase; config dependency: FSL_CORENET_RCPM depends on the PPC_E500MC. FSL_PMC depends on SUSPEND. SUSPEND depends on ARCH_SUSPEND_POSSIBLE. ARCH_SUSPEND_POSSIBLE depends on !PPC_E500MC. CONFIG_HOTPLUG_CPU and CONFIG_FSL_PMC require the timebase function, but the timebase should not depend on CONFIG_HOTPLUG_CPU and CONFIG_FSL_PMC. Therefore, adjust the macro control range. Ensure that the corresponding timebase hook function is not empty when the dtsi node is configured. ----- changes in v2: 1. add new patch: "powerpc:85xx:Fix oops when mpc85xx_smp_guts_ids node cannot be found" 2. Using !CONFIG_FSL_CORENET_RCPM to manage the timebase code of !PPC_E500MC v1: https://lore.kernel.org/lkml/20210926025144.55674-1-nixiaoming@huawei.com ------ Xiaoming Ni (2): powerpc:85xx:Fix oops when mpc85xx_smp_guts_ids node cannot be found powerpc:85xx: fix timebase sync issue when CONFIG_HOTPLUG_CPU=n arch/powerpc/platforms/85xx/Makefile | 4 +++- arch/powerpc/platforms/85xx/mpc85xx_pm_ops.c | 7 +++++-- arch/powerpc/platforms/85xx/smp.c | 12 ++++++------ 3 files changed, 14 insertions(+), 9 deletions(-) -- 2.27.0

3 years, 2 months

2
3
0 0

Drivers for Qualcomm wifi chips (ath*k) and security issues

by Pali Rohár

Hello Sasha and Greg! Last week I sent request for backporting ath9k wifi fixes for security issue CVE-2020-3702 into stable LTS kernels because Qualcomm/maintainers did not it for more months... details are in email: https://lore.kernel.org/stable/20210818084859.vcs4vs3yd6zetmyt@pali/t/#u And now I got reports that in stable LTS kernels (4.14, 4.19) are missing also other fixes for other Qualcomm wifi security issues, covered by FragAttacks codename: CVE-2020-26145 CVE-2020-26139 CVE-2020-26141 People have already asked if somebody is already doing backports to 4.19 of patches for these security issues, but there was no response, see email: https://lore.kernel.org/linux-wireless/704e1c77-6c48-79f7-043a-b2d03fbfef8b… I got information that issues for ath10k are again going to be (or are already?) fixed in some vendor custom/fork kernels, but not in official stable tree 4.14/4.19 (yet). This situation is really bad because lot of times I hear to use mainline kernel versions or official stable LTS tree (which are maintained by you), but due to such security issues in LTS trees which stays unfixed and others say to use rather vendor custom/fork kernels where it is claimed that issues are fixed. And because there is no statement for end users (end users do not communicate with vendors and so they do not have information what is supported and what not), end users just use what Linux open source distributions have in their kernels (which lot of times match official LTS kernel trees). And users think that everything is OK and security issues are fixed. So there is really a need for public statement from you or Qualcomm side, if stable LTS kernel trees are going to include security fixes for drivers used by Qualcomm wifi chips (ath*k) or not or under which conditions. And what should users / Linux distributions use if they do not want to have years-old unpatched drivers with security issues. Such information is really important also for distributions which include unmodified (or slightly modified) kernel LTS trees into their own packages. As they also need to know from which source should take (e.g. Qualcomm wifi) drivers for their systems to ensure that have security patches applied. I can understand that you or other people or volunteers do not have time to track or maintain some parts of drivers. So nothing wrong if official statement is that stable trees X and Y do not receive security updates for driver A and B anymore. Also I can understand that it takes some time to include required fixes, so expect fixes for A and B in X and Y versions with one month delay. But it is needed to know what should people expect from LTS trees for particular drivers. Because I think it is not currently clear... Do not take me wrong, I just wanted to show that this is hidden problem which needs some discussion.

3 years, 2 months

6
7
0 0

[PATCH] vfs: Check fd has read access in kernel_read_file_from_fd()

by Matthew Wilcox (Oracle)

If we open a file without read access and then pass the fd to a syscall whose implementation calls kernel_read_file_from_fd(), we get a warning from __kernel_read(): if (WARN_ON_ONCE(!(file->f_mode & FMODE_READ))) This currently affects both finit_module() and kexec_file_load(), but it could affect other syscalls in the future. Reported-by: Hao Sun <sunhao.th(a)gmail.com> Fixes: b844f0ecbc56 ("vfs: define kernel_copy_file_from_fd()") Cc: stable(a)vger.kernel.org Signed-off-by: Matthew Wilcox (Oracle) <willy(a)infradead.org> --- fs/kernel_read_file.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/kernel_read_file.c b/fs/kernel_read_file.c index 87aac4c72c37..1b07550485b9 100644 --- a/fs/kernel_read_file.c +++ b/fs/kernel_read_file.c @@ -178,7 +178,7 @@ int kernel_read_file_from_fd(int fd, loff_t offset, void **buf, struct fd f = fdget(fd); int ret = -EBADF; - if (!f.file) + if (!f.file || !(f.file->f_mode & FMODE_READ)) goto out; ret = kernel_read_file(f.file, offset, buf, buf_size, file_size, id); -- 2.32.0

3 years, 2 months

3
2
0 0

FAILED: patch "[PATCH] x86/resctrl: Free the ctrlval arrays when" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 64e87d4bd3201bf8a4685083ee4daf5c0d001452 Mon Sep 17 00:00:00 2001 From: James Morse <james.morse(a)arm.com> Date: Fri, 17 Sep 2021 16:59:58 +0000 Subject: [PATCH] x86/resctrl: Free the ctrlval arrays when domain_setup_mon_state() fails domain_add_cpu() is called whenever a CPU is brought online. The earlier call to domain_setup_ctrlval() allocates the control value arrays. If domain_setup_mon_state() fails, the control value arrays are not freed. Add the missing kfree() calls. Fixes: 1bd2a63b4f0de ("x86/intel_rdt/mba_sc: Add initialization support") Fixes: edf6fa1c4a951 ("x86/intel_rdt/cqm: Add RMID (Resource monitoring ID) management") Signed-off-by: James Morse <james.morse(a)arm.com> Signed-off-by: Borislav Petkov <bp(a)suse.de> Acked-by: Reinette Chatre <reinette.chatre(a)intel.com> Cc: <stable(a)vger.kernel.org> Link: https://lkml.kernel.org/r/20210917165958.28313-1-james.morse@arm.com diff --git a/arch/x86/kernel/cpu/resctrl/core.c b/arch/x86/kernel/cpu/resctrl/core.c index 4b8813bafffd..b5de5a6c115c 100644 --- a/arch/x86/kernel/cpu/resctrl/core.c +++ b/arch/x86/kernel/cpu/resctrl/core.c @@ -532,6 +532,8 @@ static void domain_add_cpu(int cpu, struct rdt_resource *r) } if (r->mon_capable && domain_setup_mon_state(r, d)) { + kfree(hw_dom->ctrl_val); + kfree(hw_dom->mbps_val); kfree(d); return; }

3 years, 2 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror October 2021