commit 8c20eb7e6a27b2c493b0bbb435e75cae7135634f Author: Greg Kroah-Hartman Date: Sat Feb 25 11:13:30 2023 +0100 Linux 6.2.1 Link: https://lore.kernel.org/r/20230223130426.170746546@linuxfoundation.org Link: https://lore.kernel.org/r/20230223141539.893173089@linuxfoundation.org Tested-by: Luna Jernberg Tested-by: Justin M. Forbes Tested-by: Conor Dooley Tested-by: Florian Fainelli Tested-by: Shuah Khan Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Slade Watkins Tested-by: Allen Pais Signed-off-by: Greg Kroah-Hartman commit 6113b6c51af0a54e5d06ca7d4e824a8936dc56d2 Author: Linus Torvalds Date: Wed Feb 22 09:52:32 2023 -0800 bpf: add missing header file include commit f3dd0c53370e70c0f9b7e931bbec12916f3bb8cc upstream. Commit 74e19ef0ff80 ("uaccess: Add speculation barrier to copy_from_user()") built fine on x86-64 and arm64, and that's the extent of my local build testing. It turns out those got the include incidentally through other header files ( in particular), but that was not true of other architectures, resulting in build errors kernel/bpf/core.c: In function ‘___bpf_prog_run’: kernel/bpf/core.c:1913:3: error: implicit declaration of function ‘barrier_nospec’ so just make sure to explicitly include the proper header file to make everybody see it. Fixes: 74e19ef0ff80 ("uaccess: Add speculation barrier to copy_from_user()") Reported-by: kernel test robot Reported-by: Viresh Kumar Reported-by: Huacai Chen Tested-by: Geert Uytterhoeven Tested-by: Dave Hansen Acked-by: Alexei Starovoitov Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 4752330adea4fac414a18f2e8af1a13376e8d9e5 Author: Eric Biggers Date: Tue Feb 7 22:51:33 2023 -0800 randstruct: disable Clang 15 support commit 78f7a3fd6dc66cb788c21d7705977ed13c879351 upstream. The randstruct support released in Clang 15 is unsafe to use due to a bug that can cause miscompilations: "-frandomize-layout-seed inconsistently randomizes all-function-pointers structs" (https://github.com/llvm/llvm-project/issues/60349). It has been fixed on the Clang 16 release branch, so add a Clang version check. Fixes: 035f7f87b729 ("randstruct: Enable Clang support") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Acked-by: Nick Desaulniers Reviewed-by: Nathan Chancellor Reviewed-by: Bill Wendling Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20230208065133.220589-1-ebiggers@kernel.org Signed-off-by: Greg Kroah-Hartman commit 94d8de83286fb1827340eba35b61c308f6b46ead Author: Kees Cook Date: Wed Jan 4 13:09:12 2023 -0800 ext4: Fix function prototype mismatch for ext4_feat_ktype commit 118901ad1f25d2334255b3d50512fa20591531cd upstream. With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed. ext4_feat_ktype was setting the "release" handler to "kfree", which doesn't have a matching function prototype. Add a simple wrapper with the correct prototype. This was found as a result of Clang's new -Wcast-function-type-strict flag, which is more sensitive than the simpler -Wcast-function-type, which only checks for type width mismatches. Note that this code is only reached when ext4 is a loadable module and it is being unloaded: CFI failure at kobject_put+0xbb/0x1b0 (target: kfree+0x0/0x180; expected type: 0x7c4aa698) ... RIP: 0010:kobject_put+0xbb/0x1b0 ... Call Trace: ext4_exit_sysfs+0x14/0x60 [ext4] cleanup_module+0x67/0xedb [ext4] Fixes: b99fee58a20a ("ext4: create ext4_feat kobject dynamically") Cc: Theodore Ts'o Cc: Eric Biggers Cc: stable@vger.kernel.org Build-tested-by: Gustavo A. R. Silva Reviewed-by: Gustavo A. R. Silva Reviewed-by: Nathan Chancellor Link: https://lore.kernel.org/r/20230103234616.never.915-kees@kernel.org Signed-off-by: Kees Cook Reviewed-by: Eric Biggers Link: https://lore.kernel.org/r/20230104210908.gonna.388-kees@kernel.org Signed-off-by: Greg Kroah-Hartman commit c75a91216f2ef326d631622e3c93d0bf394da123 Author: Hans de Goede Date: Fri Feb 17 15:42:08 2023 +0100 platform/x86: nvidia-wmi-ec-backlight: Add force module parameter commit 0d9bdd8a550170306c2021b8d6766c5343b870c2 upstream. On some Lenovo Legion models, the backlight might be driven by either one of nvidia_wmi_ec_backlight or amdgpu_bl0 at different times. When the Nvidia WMI EC backlight interface reports the backlight is controlled by the EC, the current backlight handling only registers nvidia_wmi_ec_backlight (and registers no other backlight interfaces). This hides (never registers) the amdgpu_bl0 interface, where as prior to 6.1.4 users would have both nvidia_wmi_ec_backlight and amdgpu_bl0 and could work around things in userspace. Add a force module parameter which can be used with acpi_backlight=native to restore the old behavior as a workound (for now) by passing: "acpi_backlight=native nvidia-wmi-ec-backlight.force=1" Fixes: 8d0ca287fd8c ("platform/x86: nvidia-wmi-ec-backlight: Use acpi_video_get_backlight_type()") Link: https://bugzilla.kernel.org/show_bug.cgi?id=217026 Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede Reviewed-by: Daniel Dadap Link: https://lore.kernel.org/r/20230217144208.5721-1-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman commit bae1b851d0a187069f7ea6014b2fe6b3ee2ded50 Author: Shyam Sundar S K Date: Mon Feb 13 17:44:57 2023 +0530 platform/x86/amd/pmf: Add depends on CONFIG_POWER_SUPPLY commit 3004e8d2a0a98bbf4223ae146464fadbff68bf78 upstream. It is reported that amd_pmf driver is missing "depends on" for CONFIG_POWER_SUPPLY causing the following build error. ld: drivers/platform/x86/amd/pmf/core.o: in function `amd_pmf_remove': core.c:(.text+0x10): undefined reference to `power_supply_unreg_notifier' ld: drivers/platform/x86/amd/pmf/core.o: in function `amd_pmf_probe': core.c:(.text+0x38f): undefined reference to `power_supply_reg_notifier' make[1]: *** [scripts/Makefile.vmlinux:34: vmlinux] Error 1 make: *** [Makefile:1248: vmlinux] Error 2 Add this to the Kconfig file. Link: https://bugzilla.kernel.org/show_bug.cgi?id=217028 Fixes: c5258d39fc4c ("platform/x86/amd/pmf: Add helper routine to update SPS thermals") Signed-off-by: Shyam Sundar S K Link: https://lore.kernel.org/r/20230213121457.1764463-1-Shyam-sundar.S-k@amd.com Cc: stable@vger.kernel.org Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman commit d1437233fc8a43af3c2f9de2f6e949ba64abd8b3 Author: Paul Moore Date: Tue Feb 7 10:21:47 2023 -0500 audit: update the mailing list in MAINTAINERS commit 6c6cd913accd77008f74a1a9d57b816db3651daa upstream. We've moved the upstream Linux Kernel audit subsystem discussions to a new mailing list, this patch updates the MAINTAINERS info with the new list address. Marking this for stable inclusion to help speed uptake of the new list across all of the supported kernel releases. This is a doc only patch so the risk should be close to nil. Cc: stable@vger.kernel.org Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 6a4bd33f9fecf743014b80a00b29bf095b525eb7 Author: Lukas Wunner Date: Fri Jan 27 15:01:00 2023 +0100 wifi: mwifiex: Add missing compatible string for SD8787 commit 36dd7a4c6226133b0b7aa92b8e604e688d958d0c upstream. Commit e3fffc1f0b47 ("devicetree: document new marvell-8xxx and pwrseq-sd8787 options") documented a compatible string for SD8787 in the devicetree bindings, but neglected to add it to the mwifiex driver. Fixes: e3fffc1f0b47 ("devicetree: document new marvell-8xxx and pwrseq-sd8787 options") Signed-off-by: Lukas Wunner Cc: stable@vger.kernel.org # v4.11+ Cc: Matt Ranostay Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/320de5005ff3b8fd76be2d2b859fd021689c3681.1674827105.git.lukas@wunner.de Signed-off-by: Greg Kroah-Hartman commit 5dc297652dbc557eba7ca7d6a4c5f1940dffffb1 Author: Benjamin Tissoires Date: Thu Feb 16 11:22:58 2023 +0100 HID: mcp-2221: prevent UAF in delayed work commit 47e91fdfa511139f2549687edb0d8649b123227b upstream. If the device is plugged/unplugged without giving time for mcp_init_work() to complete, we might kick in the devm free code path and thus have unavailable struct mcp_2221 while in delayed work. Canceling the delayed_work item is enough to solve the issue, because cancel_delayed_work_sync will prevent the work item to requeue itself. Fixes: 960f9df7c620 ("HID: mcp2221: add ADC/DAC support via iio subsystem") CC: stable@vger.kernel.org Acked-by: Jiri Kosina Link: https://lore.kernel.org/r/20230215-wip-mcp2221-v2-1-109f71fd036e@redhat.com Signed-off-by: Benjamin Tissoires Signed-off-by: Greg Kroah-Hartman commit 7a7857b644e1cbe08e0b1160b1f3761b3bbd09e6 Author: Peter Zijlstra Date: Thu Jan 26 16:34:27 2023 +0100 x86/static_call: Add support for Jcc tail-calls commit 923510c88d2b7d947c4217835fd9ca6bd65cc56c upstream. Clang likes to create conditional tail calls like: 0000000000000350 : 350: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) 351: R_X86_64_NONE __fentry__-0x4 355: 48 83 bf 20 01 00 00 00 cmpq $0x0,0x120(%rdi) 35d: 0f 85 00 00 00 00 jne 363 35f: R_X86_64_PLT32 __SCT__amd_pmu_branch_add-0x4 363: e9 00 00 00 00 jmp 368 364: R_X86_64_PLT32 __x86_return_thunk-0x4 Where 0x35d is a static call site that's turned into a conditional tail-call using the Jcc class of instructions. Teach the in-line static call text patching about this. Notably, since there is no conditional-ret, in that case patch the Jcc to point at an empty stub function that does the ret -- or the return thunk when needed. Reported-by: "Erhard F." Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Reviewed-by: Masami Hiramatsu (Google) Link: https://lore.kernel.org/r/Y9Kdg9QjHkr9G5b5@hirez.programming.kicks-ass.net Cc: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit cb018fee513c42d4f449f31c1b6703d9c9386ae9 Author: Peter Zijlstra Date: Mon Jan 23 21:59:17 2023 +0100 x86/alternatives: Teach text_poke_bp() to patch Jcc.d32 instructions commit ac0ee0a9560c97fa5fe1409e450c2425d4ebd17a upstream. In order to re-write Jcc.d32 instructions text_poke_bp() needs to be taught about them. The biggest hurdle is that the whole machinery is currently made for 5 byte instructions and extending this would grow struct text_poke_loc which is currently a nice 16 bytes and used in an array. However, since text_poke_loc contains a full copy of the (s32) displacement, it is possible to map the Jcc.d32 2 byte opcodes to Jcc.d8 1 byte opcode for the int3 emulation. This then leaves the replacement bytes; fudge that by only storing the last 5 bytes and adding the rule that 'length == 6' instruction will be prefixed with a 0x0f byte. Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Reviewed-by: Masami Hiramatsu (Google) Link: https://lore.kernel.org/r/20230123210607.115718513@infradead.org Cc: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit a3ab0272c91bba96457eff0f8682d6b013cc110e Author: Peter Zijlstra Date: Mon Jan 23 21:59:16 2023 +0100 x86/alternatives: Introduce int3_emulate_jcc() commit db7adcfd1cec4e95155e37bc066fddab302c6340 upstream. Move the kprobe Jcc emulation into int3_emulate_jcc() so it can be used by more code -- specifically static_call() will need this. Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Reviewed-by: Masami Hiramatsu (Google) Link: https://lore.kernel.org/r/20230123210607.057678245@infradead.org Cc: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit 2c8ee21d78942cf48bc836612ad365fd6f06cfbb Author: Dave Hansen Date: Tue Feb 21 12:30:15 2023 -0800 uaccess: Add speculation barrier to copy_from_user() commit 74e19ef0ff8061ef55957c3abd71614ef0f42f47 upstream. The results of "access_ok()" can be mis-speculated. The result is that you can end speculatively: if (access_ok(from, size)) // Right here even for bad from/size combinations. On first glance, it would be ideal to just add a speculation barrier to "access_ok()" so that its results can never be mis-speculated. But there are lots of system calls just doing access_ok() via "copy_to_user()" and friends (example: fstat() and friends). Those are generally not problematic because they do not _consume_ data from userspace other than the pointer. They are also very quick and common system calls that should not be needlessly slowed down. "copy_from_user()" on the other hand uses a user-controller pointer and is frequently followed up with code that might affect caches. Take something like this: if (!copy_from_user(&kernelvar, uptr, size)) do_something_with(kernelvar); If userspace passes in an evil 'uptr' that *actually* points to a kernel addresses, and then do_something_with() has cache (or other) side-effects, it could allow userspace to infer kernel data values. Add a barrier to the common copy_from_user() code to prevent mis-speculated values which happen after the copy. Also add a stub for architectures that do not define barrier_nospec(). This makes the macro usable in generic code. Since the barrier is now usable in generic code, the x86 #ifdef in the BPF code can also go away. Reported-by: Jordy Zomer Suggested-by: Linus Torvalds Signed-off-by: Dave Hansen Reviewed-by: Thomas Gleixner Acked-by: Daniel Borkmann # BPF bits Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman