kernel/linux.git/scripts, branch v6.1.66

randstruct: Fix gcc-plugin performance mode to stay in group

2023-11-28T17:07:07+00:00

commit 381fdb73d1e2a48244de7260550e453d1003bb8e upstream. The performance mode of the gcc-plugin randstruct was shuffling struct members outside of the cache-line groups. Limit the range to the specified group indexes. Cc: linux-hardening@vger.kernel.org Cc: stable@vger.kernel.org Reported-by: Lukas Loidolt Closes: https://lore.kernel.org/all/f3ca77f0-e414-4065-83a5-ae4c4d25545d@student.tuwien.ac.at Fixes: 313dd1b62921 ("gcc-plugins: Add the randstruct plugin") Signed-off-by: Kees Cook Signed-off-by: Greg Kroah-Hartman

modpost: fix ishtp MODULE_DEVICE_TABLE built on big-endian host

2023-11-20T10:52:12+00:00

[ Upstream commit ac96a15a0f0c8812a3aaa587b871cd5527f6d736 ] When MODULE_DEVICE_TABLE(ishtp, ) is built on a host with a different endianness from the target architecture, it results in an incorrect MODULE_ALIAS(). For example, see a case where drivers/platform/x86/intel/ishtp_eclite.c is built as a module for x86. If you build it on a little-endian host, you will get the correct MODULE_ALIAS: $ grep MODULE_ALIAS drivers/platform/x86/intel/ishtp_eclite.mod.c MODULE_ALIAS("ishtp:{6A19CC4B-D760-4DE3-B14D-F25EBD0FBCD9}"); However, if you build it on a big-endian host, you will get a wrong MODULE_ALIAS: $ grep MODULE_ALIAS drivers/platform/x86/intel/ishtp_eclite.mod.c MODULE_ALIAS("ishtp:{BD0FBCD9-F25E-B14D-4DE3-D7606A19CC4B}"); This issue has been unnoticed because the x86 kernel is most likely built natively on an x86 host. The guid field must not be reversed because guid_t is an array of __u8. Fixes: fa443bc3c1e4 ("HID: intel-ish-hid: add support for MODULE_DEVICE_TABLE()") Signed-off-by: Masahiro Yamada Reviewed-by: Thomas Weißschuh Tested-by: Srinivas Pandruvada Acked-by: Srinivas Pandruvada Signed-off-by: Sasha Levin

modpost: fix tee MODULE_DEVICE_TABLE built on big-endian host

2023-11-20T10:52:12+00:00

[ Upstream commit 7f54e00e5842663c2cea501bbbdfa572c94348a3 ] When MODULE_DEVICE_TABLE(tee, ) is built on a host with a different endianness from the target architecture, it results in an incorrect MODULE_ALIAS(). For example, see a case where drivers/char/hw_random/optee-rng.c is built as a module for ARM little-endian. If you build it on a little-endian host, you will get the correct MODULE_ALIAS: $ grep MODULE_ALIAS drivers/char/hw_random/optee-rng.mod.c MODULE_ALIAS("tee:ab7a617c-b8e7-4d8f-8301-d09b61036b64*"); However, if you build it on a big-endian host, you will get a wrong MODULE_ALIAS: $ grep MODULE_ALIAS drivers/char/hw_random/optee-rng.mod.c MODULE_ALIAS("tee:646b0361-9bd0-0183-8f4d-e7b87c617aab*"); The same problem also occurs when you enable CONFIG_CPU_BIG_ENDIAN, and build it on a little-endian host. This issue has been unnoticed because the ARM kernel is configured for little-endian by default, and most likely built on a little-endian host (cross-build on x86 or native-build on ARM). The uuid field must not be reversed because uuid_t is an array of __u8. Fixes: 0fc1db9d1059 ("tee: add bus driver framework for TEE based devices") Signed-off-by: Masahiro Yamada Reviewed-by: Sumit Garg Signed-off-by: Sasha Levin

kallsyms: Reduce the memory occupied by kallsyms_seqs_of_names[]

2023-10-25T10:03:16+00:00

[ Upstream commit 19bd8981dc2ee35fdc81ab1b0104b607c917d470 ] kallsyms_seqs_of_names[] records the symbol index sorted by address, the maximum value in kallsyms_seqs_of_names[] is the number of symbols. And 2^24 = 16777216, which means that three bytes are enough to store the index. This can help us save (1 * kallsyms_num_syms) bytes of memory. Signed-off-by: Zhen Lei Signed-off-by: Luis Chamberlain Stable-dep-of: b022f0c7e404 ("tracing/kprobes: Return EADDRNOTAVAIL when func matches several symbols") Signed-off-by: Sasha Levin

modpost: add missing else to the "of" check

2023-10-10T20:00:41+00:00

[ Upstream commit cbc3d00cf88fda95dbcafee3b38655b7a8f2650a ] Without this 'else' statement, an "usb" name goes into two handlers: the first/previous 'if' statement _AND_ the for-loop over 'devtable', but the latter is useless as it has no 'usb' device_id entry anyway. Tested with allmodconfig before/after patch; no changes to *.mod.c: git checkout v6.6-rc3 make -j$(nproc) allmodconfig make -j$(nproc) olddefconfig make -j$(nproc) find . -name '*.mod.c' | cpio -pd /tmp/before # apply patch make -j$(nproc) find . -name '*.mod.c' | cpio -pd /tmp/after diff -r /tmp/before/ /tmp/after/ # no difference Fixes: acbef7b76629 ("modpost: fix module autoloading for OF devices with generic compatible property") Signed-off-by: Mauricio Faria de Oliveira Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin

kconfig: fix possible buffer overflow

2023-09-19T10:27:59+00:00

[ Upstream commit a3b7039bb2b22fcd2ad20d59c00ed4e606ce3754 ] Buffer 'new_argv' is accessed without bound check after accessing with bound check via 'new_argc' index. Fixes: e298f3b49def ("kconfig: add built-in function support") Co-developed-by: Ivanov Mikhail Signed-off-by: Konstantin Meskhidze Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin

kbuild: rpm-pkg: define _arch conditionally

2023-09-19T10:27:58+00:00

[ Upstream commit 233046a2afd12a4f699305b92ee634eebf1e4f31 ] Commit 3089b2be0cce ("kbuild: rpm-pkg: fix build error when _arch is undefined") does not work as intended; _arch is always defined as $UTS_MACHINE. The intention was to define _arch to $UTS_MACHINE only when it is not defined. Fixes: 3089b2be0cce ("kbuild: rpm-pkg: fix build error when _arch is undefined") Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin

kbuild: rust_is_available: fix confusion when a version appears in the path

2023-09-13T07:42:32+00:00

[ Upstream commit 9eb7e20e0c5cd069457845f965b3e8a7d736ecb7 ] `bindgen`'s output for `libclang`'s version check contains paths, which in turn may contain strings that look like version numbers [1][2]: .../6.1.0-dev/.../rust_is_available_bindgen_libclang.h:2:9: warning: clang version 11.1.0 [-W#pragma-messages], err: false which the script will pick up as the version instead of the latter. It is also the case that versions may appear after the actual version (e.g. distribution's version text), which was the reason behind `head` [3]: .../rust-is-available-bindgen-libclang.h:2:9: warning: clang version 13.0.0 (Fedora 13.0.0-3.fc35) [-W#pragma-messages], err: false Thus instead ask for a match after the `clang version` string. Reported-by: Jordan Isaacs Closes: https://github.com/Rust-for-Linux/linux/issues/942 [1] Reported-by: "Ethan D. Twardy" Closes: https://lore.kernel.org/rust-for-linux/20230528131802.6390-2-ethan.twardy@gmail.com/ [2] Reported-by: Tiago Lam Closes: https://github.com/Rust-for-Linux/linux/pull/789 [3] Fixes: 78521f3399ab ("scripts: add `rust_is_available.sh`") Reviewed-by: Martin Rodriguez Reboredo Reviewed-by: Ethan Twardy Tested-by: Ethan Twardy Reviewed-by: Nathan Chancellor Link: https://lore.kernel.org/r/20230616001631.463536-8-ojeda@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin

kbuild: rust_is_available: add check for `bindgen` invocation

2023-09-13T07:42:32+00:00

[ Upstream commit 52cae7f28ed6c3992489f16bb355f5b623f0912e ] `scripts/rust_is_available.sh` calls `bindgen` with a special header in order to check whether the `libclang` version in use is suitable. However, the invocation itself may fail if, for instance, `bindgen` cannot locate `libclang`. This is fine for Kconfig (since the script will still fail and therefore disable Rust as it should), but it is pretty confusing for users of the `rustavailable` target given the error will be unrelated: ./scripts/rust_is_available.sh: 21: arithmetic expression: expecting primary: "100000 * + 100 * + " make: *** [Makefile:1816: rustavailable] Error 2 Instead, run the `bindgen` invocation independently in a previous step, saving its output and return code. If it fails, then show the user a proper error message. Otherwise, continue as usual with the saved output. Since the previous patch we show a reference to the docs, and the docs now explain how `bindgen` looks for `libclang`, thus the error message can leverage the documentation, avoiding duplication here (and making users aware of the setup guide in the documentation). Reported-by: Nick Desaulniers Link: https://lore.kernel.org/rust-for-linux/CAKwvOdm5JT4wbdQQYuW+RT07rCi6whGBM2iUAyg8A1CmLXG6Nw@mail.gmail.com/ Reported-by: François Valenduc Closes: https://github.com/Rust-for-Linux/linux/issues/934 Reported-by: Alexandru Radovici Closes: https://github.com/Rust-for-Linux/linux/pull/921 Reported-by: Matthew Leach Closes: https://lore.kernel.org/rust-for-linux/20230507084116.1099067-1-dev@mattleach.net/ Fixes: 78521f3399ab ("scripts: add `rust_is_available.sh`") Reviewed-by: Martin Rodriguez Reboredo Reviewed-by: Masahiro Yamada Reviewed-by: Nathan Chancellor Link: https://lore.kernel.org/r/20230616001631.463536-6-ojeda@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin

kbuild: rust_is_available: fix version check when CC has multiple arguments

2023-09-13T07:42:32+00:00

[ Upstream commit dee3a6b819c96fc8b1907577f585fd66f5c0fefe ] rust_is_available.sh uses cc-version.sh to identify which C compiler is in use, as scripts/Kconfig.include does. cc-version.sh isn't designed to be able to handle multiple arguments in one variable, i.e. "ccache clang". Its invocation in rust_is_available.sh quotes "$CC", which makes $1 == "ccache clang" instead of the intended $1 == ccache & $2 == clang. cc-version.sh could also be changed to handle having "ccache clang" as one argument, but it only has the one consumer upstream, making it simpler to fix the caller here. Signed-off-by: Russell Currey Fixes: 78521f3399ab ("scripts: add `rust_is_available.sh`") Link: https://github.com/Rust-for-Linux/linux/pull/873 [ Reworded title prefix and reflow line to 75 columns. ] Reviewed-by: Martin Rodriguez Reboredo Reviewed-by: Nathan Chancellor Link: https://lore.kernel.org/r/20230616001631.463536-3-ojeda@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin