commit 5dbeb9f76cef6e1b3ba9e8dbf1a3fa276ae0f5d2 Author: Greg Kroah-Hartman Date: Sun Nov 22 10:15:33 2020 +0100 Linux 5.9.10 Tested-by: Jon Hunter Tested-by: Jeffrin Jose T Tested-by: Shuah Khan Tested-by: Linux Kernel Functional Testing Tested-by: Guenter Roeck Link: https://lore.kernel.org/r/20201120104541.168007611@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit aeb3c71085fdbfd7a73e99199bd1c16a09d6ed8d Author: Nick Desaulniers Date: Sat Nov 7 00:49:39 2020 -0800 ACPI: GED: fix -Wformat commit 9debfb81e7654fe7388a49f45bc4d789b94c1103 upstream. Clang is more aggressive about -Wformat warnings when the format flag specifies a type smaller than the parameter. It turns out that gsi is an int. Fixes: drivers/acpi/evged.c:105:48: warning: format specifies type 'unsigned char' but the argument has type 'unsigned int' [-Wformat] trigger == ACPI_EDGE_SENSITIVE ? 'E' : 'L', gsi); ^~~ Link: https://github.com/ClangBuiltLinux/linux/issues/378 Fixes: ea6f3af4c5e6 ("ACPI: GED: add support for _Exx / _Lxx handler methods") Acked-by: Ard Biesheuvel Signed-off-by: Nick Desaulniers Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 312630a7d5af96a4b6c939837f203cadf72e59f6 Author: David Edmondson Date: Tue Nov 3 12:04:00 2020 +0000 KVM: x86: clflushopt should be treated as a no-op by emulation commit 51b958e5aeb1e18c00332e0b37c5d4e95a3eff84 upstream. The instruction emulator ignores clflush instructions, yet fails to support clflushopt. Treat both similarly. Fixes: 13e457e0eebf ("KVM: x86: Emulator does not decode clflush well") Signed-off-by: David Edmondson Message-Id: <20201103120400.240882-1-david.edmondson@oracle.com> Reviewed-by: Joao Martins Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 6a3ecd17b2f8853700cf34af36e29ec0f6d8a17c Author: Arnd Bergmann Date: Mon Oct 26 22:51:57 2020 +0100 perf/x86/intel/uncore: Fix Add BW copypasta commit 1a8cfa24e21c2f154791f0cdd85fc28496918722 upstream. gcc -Wextra points out a duplicate initialization of one array member: arch/x86/events/intel/uncore_snb.c:478:37: warning: initialized field overwritten [-Woverride-init] 478 | [SNB_PCI_UNCORE_IMC_DATA_READS] = { SNB_UNCORE_PCI_IMC_DATA_WRITES_BASE, The only sensible explanation is that a duplicate 'READS' was used instead of the correct 'WRITES', so change it back. Fixes: 24633d901ea4 ("perf/x86/intel/uncore: Add BW counters for GT, IA and IO breakdown") Signed-off-by: Arnd Bergmann Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20201026215203.3893972-1-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman commit a048ffdf85506fa3489d38ed47a88f80d63e2194 Author: Qian Cai Date: Wed Oct 28 14:23:34 2020 -0400 powerpc/smp: Call rcu_cpu_starting() earlier commit 99f070b62322a4b8c1252952735806d09eb44b68 upstream. The call to rcu_cpu_starting() in start_secondary() is not early enough in the CPU-hotplug onlining process, which results in lockdep splats as follows (with CONFIG_PROVE_RCU_LIST=y): WARNING: suspicious RCU usage ----------------------------- kernel/locking/lockdep.c:3497 RCU-list traversed in non-reader section!! other info that might help us debug this: RCU used illegally from offline CPU! rcu_scheduler_active = 1, debug_locks = 1 no locks held by swapper/1/0. Call Trace: dump_stack+0xec/0x144 (unreliable) lockdep_rcu_suspicious+0x128/0x14c __lock_acquire+0x1060/0x1c60 lock_acquire+0x140/0x5f0 _raw_spin_lock_irqsave+0x64/0xb0 clockevents_register_device+0x74/0x270 register_decrementer_clockevent+0x94/0x110 start_secondary+0x134/0x800 start_secondary_prolog+0x10/0x14 This is avoided by adding a call to rcu_cpu_starting() near the beginning of the start_secondary() function. Note that the raw_smp_processor_id() is required in order to avoid calling into lockdep before RCU has declared the CPU to be watched for readers. It's safe to call rcu_cpu_starting() in the arch code as well as later in generic code, as explained by Paul: It uses a per-CPU variable so that RCU pays attention only to the first call to rcu_cpu_starting() if there is more than one of them. This is even intentional, due to there being a generic arch-independent call to rcu_cpu_starting() in notify_cpu_starting(). So multiple calls to rcu_cpu_starting() are fine by design. Fixes: 4d004099a668 ("lockdep: Fix lockdep recursion") Signed-off-by: Qian Cai Acked-by: Paul E. McKenney [mpe: Add Fixes tag, reword slightly & expand change log] Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20201028182334.13466-1-cai@redhat.com Signed-off-by: Greg Kroah-Hartman commit 022f47b5a4e6bd69da89b984aca01edaced6b095 Author: Tommi Rantala Date: Thu Oct 8 15:26:24 2020 +0300 selftests/harness: prettify SKIP message whitespace again commit ef7086347c82c53a6c5238bd2cf31379f6acadde upstream. Commit 9847d24af95c ("selftests/harness: Refactor XFAIL into SKIP") replaced XFAIL with SKIP in the output. Add one more space to make the output aligned and pretty again. Fixes: 9847d24af95c ("selftests/harness: Refactor XFAIL into SKIP") Signed-off-by: Tommi Rantala Acked-by: Kees Cook Reviewed-by: Christian Brauner Signed-off-by: Shuah Khan Signed-off-by: Greg Kroah-Hartman commit d56b58aba072027aa1fe6d9260a3e273585124cf Author: Zhang Changzhong Date: Tue Jul 14 14:44:50 2020 +0800 can: proc: can_remove_proc(): silence remove_proc_entry warning commit 3accbfdc36130282f5ae9e6eecfdf820169fedce upstream. If can_init_proc() fail to create /proc/net/can directory, can_remove_proc() will trigger a warning: WARNING: CPU: 6 PID: 7133 at fs/proc/generic.c:672 remove_proc_entry+0x17b0 Kernel panic - not syncing: panic_on_warn set ... Fix to return early from can_remove_proc() if can proc_dir does not exists. Signed-off-by: Zhang Changzhong Link: https://lore.kernel.org/r/1594709090-3203-1-git-send-email-zhangchangzhong@huawei.com Fixes: 8e8cda6d737d ("can: initial support for network namespaces") Acked-by: Oliver Hartkopp Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 03d5c11b7b4a07220275528335001b9b8be839b0 Author: Johannes Berg Date: Fri Oct 9 14:17:11 2020 +0200 mac80211: always wind down STA state commit dcd479e10a0510522a5d88b29b8f79ea3467d501 upstream. When (for example) an IBSS station is pre-moved to AUTHORIZED before it's inserted, and then the insertion fails, we don't clean up the fast RX/TX states that might already have been created, since we don't go through all the state transitions again on the way down. Do that, if it hasn't been done already, when the station is freed. I considered only freeing the fast TX/RX state there, but we might add more state so it's more robust to wind down the state properly. Note that we warn if the station was ever inserted, it should have been properly cleaned up in that case, and the driver will probably not like things happening out of order. Reported-by: syzbot+2e293dbd67de2836ba42@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/20201009141710.7223b322a955.I95bd08b9ad0e039c034927cce0b75beea38e059b@changeid Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 88d9fe1e1487a5a084c12d4e92ec40b908553ce2 Author: Dmitry Torokhov Date: Mon Oct 26 13:36:17 2020 -0700 Input: sunkbd - avoid use-after-free in teardown paths commit 77e70d351db7de07a46ac49b87a6c3c7a60fca7e upstream. We need to make sure we cancel the reinit work before we tear down the driver structures. Reported-by: Bodong Zhao Tested-by: Bodong Zhao Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit b871e3a7a70e5cfaab6e8b1159e66e217fdedb23 Author: Gabriel David Date: Fri Oct 2 18:27:00 2020 -0400 leds: lm3697: Fix out-of-bound access commit 98d278ca00bd8f62c8bc98bd9e65372d16eb6956 upstream If both LED banks aren't used in device tree, an out-of-bounds condition in lm3697_init occurs because of the for loop assuming that all the banks are used. Fix it by adding a variable that contains the number of used banks. Signed-off-by: Gabriel David [removed extra rename, minor tweaks] Signed-off-by: Pavel Machek Cc: stable@kernel.org [sudip: use client->dev] Signed-off-by: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman commit 12eb3aedbc7b201d7856d87a1044323219aeff04 Author: Daniel Axtens Date: Fri Nov 20 10:22:50 2020 +1100 selftests/powerpc: entry flush test commit 89a83a0c69c81a25ce91002b90ca27ed86132a0a upstream. Add a test modelled on the RFI flush test which counts the number of L1D misses doing a simple syscall with the entry flush on and off. For simplicity of backporting, this test duplicates a lot of code from rfi_flush. We clean that up in the next patch. Signed-off-by: Daniel Axtens Signed-off-by: Greg Kroah-Hartman commit 8db6f38cab14b09aea6e21da6438dad278517abc Author: Michael Ellerman Date: Fri Nov 20 10:22:49 2020 +1100 powerpc: Only include kup-radix.h for 64-bit Book3S commit 178d52c6e89c38d0553b0ac8b99927b11eb995b0 upstream. In kup.h we currently include kup-radix.h for all 64-bit builds, which includes Book3S and Book3E. The latter doesn't make sense, Book3E never uses the Radix MMU. This has worked up until now, but almost by accident, and the recent uaccess flush changes introduced a build breakage on Book3E because of the bad structure of the code. So disentangle things so that we only use kup-radix.h for Book3S. This requires some more stubs in kup.h and fixing an include in syscall_64.c. Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit ab13e7fce101aabea634b4087bfc0f4a131e8bff Author: Nicholas Piggin Date: Fri Nov 20 10:22:48 2020 +1100 powerpc/64s: flush L1D after user accesses commit 9a32a7e78bd0cd9a9b6332cbdc345ee5ffd0c5de upstream. IBM Power9 processors can speculatively operate on data in the L1 cache before it has been completely validated, via a way-prediction mechanism. It is not possible for an attacker to determine the contents of impermissible memory using this method, since these systems implement a combination of hardware and software security measures to prevent scenarios where protected data could be leaked. However these measures don't address the scenario where an attacker induces the operating system to speculatively execute instructions using data that the attacker controls. This can be used for example to speculatively bypass "kernel user access prevention" techniques, as discovered by Anthony Steinhauser of Google's Safeside Project. This is not an attack by itself, but there is a possibility it could be used in conjunction with side-channels or other weaknesses in the privileged code to construct an attack. This issue can be mitigated by flushing the L1 cache between privilege boundaries of concern. This patch flushes the L1 cache after user accesses. This is part of the fix for CVE-2020-4788. Signed-off-by: Nicholas Piggin Signed-off-by: Daniel Axtens Signed-off-by: Greg Kroah-Hartman commit e590b36718d6e740b7b19514f710402a6499164c Author: Nicholas Piggin Date: Fri Nov 20 10:22:47 2020 +1100 powerpc/64s: flush L1D on kernel entry commit f79643787e0a0762d2409b7b8334e83f22d85695 upstream. IBM Power9 processors can speculatively operate on data in the L1 cache before it has been completely validated, via a way-prediction mechanism. It is not possible for an attacker to determine the contents of impermissible memory using this method, since these systems implement a combination of hardware and software security measures to prevent scenarios where protected data could be leaked. However these measures don't address the scenario where an attacker induces the operating system to speculatively execute instructions using data that the attacker controls. This can be used for example to speculatively bypass "kernel user access prevention" techniques, as discovered by Anthony Steinhauser of Google's Safeside Project. This is not an attack by itself, but there is a possibility it could be used in conjunction with side-channels or other weaknesses in the privileged code to construct an attack. This issue can be mitigated by flushing the L1 cache between privilege boundaries of concern. This patch flushes the L1 cache on kernel entry. This is part of the fix for CVE-2020-4788. Signed-off-by: Nicholas Piggin Signed-off-by: Daniel Axtens Signed-off-by: Greg Kroah-Hartman commit 401ef334343a305f9e1582920b81d8d731fa78ff Author: Russell Currey Date: Fri Nov 20 10:22:46 2020 +1100 selftests/powerpc: rfi_flush: disable entry flush if present commit fcb48454c23c5679d1a2e252f127642e91b05cbe upstream. We are about to add an entry flush. The rfi (exit) flush test measures the number of L1D flushes over a syscall with the RFI flush enabled and disabled. But if the entry flush is also enabled, the effect of enabling and disabling the RFI flush is masked. If there is a debugfs entry for the entry flush, disable it during the RFI flush and restore it later. Reported-by: Spoorthy S Signed-off-by: Russell Currey Signed-off-by: Daniel Axtens Signed-off-by: Greg Kroah-Hartman