November 2024 - Linux-stable-mirror

[PATCH v4] memfd: `MFD_NOEXEC_SEAL` should not imply `MFD_ALLOW_SEALING`

by Barnabás Pőcze

`MFD_NOEXEC_SEAL` should remove the executable bits and set `F_SEAL_EXEC` to prevent further modifications to the executable bits as per the comment in the uapi header file: not executable and sealed to prevent changing to executable However, commit 105ff5339f498a ("mm/memfd: add MFD_NOEXEC_SEAL and MFD_EXEC") that introduced this feature made it so that `MFD_NOEXEC_SEAL` unsets `F_SEAL_SEAL`, essentially acting as a superset of `MFD_ALLOW_SEALING`. Nothing implies that it should be so, and indeed up until the second version of the of the patchset[0] that introduced `MFD_EXEC` and `MFD_NOEXEC_SEAL`, `F_SEAL_SEAL` was not removed, however, it was changed in the third revision of the patchset[1] without a clear explanation. This behaviour is surprising for application developers, there is no documentation that would reveal that `MFD_NOEXEC_SEAL` has the additional effect of `MFD_ALLOW_SEALING`. Additionally, combined with `vm.memfd_noexec=2` it has the effect of making all memfds initially sealable. So do not remove `F_SEAL_SEAL` when `MFD_NOEXEC_SEAL` is requested, thereby returning to the pre-Linux 6.3 behaviour of only allowing sealing when `MFD_ALLOW_SEALING` is specified. Now, this is technically a uapi break. However, the damage is expected to be minimal. To trigger user visible change, a program has to do the following steps: - create memfd: - with `MFD_NOEXEC_SEAL`, - without `MFD_ALLOW_SEALING`; - try to add seals / check the seals. But that seems unlikely to happen intentionally since this change essentially reverts the kernel's behaviour to that of Linux <6.3, so if a program worked correctly on those older kernels, it will likely work correctly after this change. I have used Debian Code Search and GitHub to try to find potential breakages, and I could only find a single one. dbus-broker's memfd_create() wrapper is aware of this implicit `MFD_ALLOW_SEALING` behaviour, and tries to work around it[2]. This workaround will break. Luckily, this only affects the test suite, it does not affect the normal operations of dbus-broker. There is a PR with a fix[3]. I also carried out a smoke test by building a kernel with this change and booting an Arch Linux system into GNOME and Plasma sessions. There was also a previous attempt to address this peculiarity by introducing a new flag[4]. [0]: https://lore.kernel.org/lkml/20220805222126.142525-3-jeffxu@google.com/ [1]: https://lore.kernel.org/lkml/20221202013404.163143-3-jeffxu@google.com/ [2]: https://github.com/bus1/dbus-broker/blob/9eb0b7e5826fc76cad7b025bc46f267d4a… [3]: https://github.com/bus1/dbus-broker/pull/366 [4]: https://lore.kernel.org/lkml/20230714114753.170814-1-david@readahead.eu/ Cc: stable(a)vger.kernel.org Signed-off-by: Barnabás Pőcze <pobrn(a)protonmail.com> --- * v3: https://lore.kernel.org/linux-mm/20240611231409.3899809-1-jeffxu@chromium.o… * v2: https://lore.kernel.org/linux-mm/20240524033933.135049-1-jeffxu@google.com/ * v1: https://lore.kernel.org/linux-mm/20240513191544.94754-1-pobrn@protonmail.co… This fourth version returns to removing the inconsistency as opposed to documenting its existence, with the same code change as v1 but with a somewhat extended commit message. This is sent because I believe it is worth at least a try; it can be easily reverted if bigger application breakages are discovered than initially imagined. --- mm/memfd.c | 9 ++++----- tools/testing/selftests/memfd/memfd_test.c | 2 +- 2 files changed, 5 insertions(+), 6 deletions(-) diff --git a/mm/memfd.c b/mm/memfd.c index 7d8d3ab3fa37..8b7f6afee21d 100644 --- a/mm/memfd.c +++ b/mm/memfd.c @@ -356,12 +356,11 @@ SYSCALL_DEFINE2(memfd_create, inode->i_mode &= ~0111; file_seals = memfd_file_seals_ptr(file); - if (file_seals) { - *file_seals &= ~F_SEAL_SEAL; + if (file_seals) *file_seals |= F_SEAL_EXEC; - } - } else if (flags & MFD_ALLOW_SEALING) { - /* MFD_EXEC and MFD_ALLOW_SEALING are set */ + } + + if (flags & MFD_ALLOW_SEALING) { file_seals = memfd_file_seals_ptr(file); if (file_seals) *file_seals &= ~F_SEAL_SEAL; diff --git a/tools/testing/selftests/memfd/memfd_test.c b/tools/testing/selftests/memfd/memfd_test.c index 95af2d78fd31..7b78329f65b6 100644 --- a/tools/testing/selftests/memfd/memfd_test.c +++ b/tools/testing/selftests/memfd/memfd_test.c @@ -1151,7 +1151,7 @@ static void test_noexec_seal(void) mfd_def_size, MFD_CLOEXEC | MFD_NOEXEC_SEAL); mfd_assert_mode(fd, 0666); - mfd_assert_has_seals(fd, F_SEAL_EXEC); + mfd_assert_has_seals(fd, F_SEAL_SEAL | F_SEAL_EXEC); mfd_fail_chmod(fd, 0777); close(fd); } -- 2.45.2

7 months, 1 week

3
4
0 0

[PATCH 0/6] firmware: qcom: scm: Fixes for concurrency

by Krzysztof Kozlowski

SCM driver looks messy in terms of handling concurrency of probe. The driver exports interface which is guarded by global '__scm' variable but: 1. Lacks proper read barrier (commit adding write barriers mixed up READ_ONCE with a read barrier). 2. Lacks barriers or checks for '__scm' in multiple places. 3. Lacks probe error cleanup. I fixed here few visible things, but this was not tested extensively. I tried only SM8450. ARM32 and SC8280xp/X1E platforms would be useful for testing as well. All the issues here are non-urgent, IOW, they were here for some time (v6.10-rc1 and earlier). Best regards, Krzysztof --- Krzysztof Kozlowski (6): firmware: qcom: scm: Fix missing read barrier in qcom_scm_is_available() firmware: qcom: scm: Fix missing read barrier in qcom_scm_get_tzmem_pool() firmware: qcom: scm: Handle various probe ordering for qcom_scm_assign_mem() [RFC/RFT] firmware: qcom: scm: Cleanup global '__scm' on probe failures firmware: qcom: scm: smc: Handle missing SCM device firmware: qcom: scm: smc: Narrow 'mempool' variable scope drivers/firmware/qcom/qcom_scm-smc.c | 6 +++- drivers/firmware/qcom/qcom_scm.c | 55 +++++++++++++++++++++++++----------- 2 files changed, 44 insertions(+), 17 deletions(-) --- base-commit: 414c97c966b69e4a6ea7b32970fa166b2f9b9ef0 change-id: 20241119-qcom-scm-missing-barriers-and-all-sort-of-srap-a25d59074882 Best regards, -- Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org>

7 months, 1 week

4
6
0 0

[PATCH v3 0/2] media: uvcvideo: Support partial control reads and minor changes

by Ricardo Ribalda

Some cameras do not return all the bytes requested from a control if it can fit in less bytes. Eg: returning 0xab instead of 0x00ab. Support these devices. Also, now that we are at it, improve uvc_query_ctrl() logging. Signed-off-by: Ricardo Ribalda <ribalda(a)chromium.org> --- Changes in v3: - Improve documentation. - Do not change return sequence. - Use dev_ratelimit and dev_warn_once - Link to v2: https://lore.kernel.org/r/20241008-uvc-readless-v2-0-04d9d51aee56@chromium.… Changes in v2: - Rewrite error handling (Thanks Sakari) - Discard 2/3. It is not needed after rewriting the error handling. - Link to v1: https://lore.kernel.org/r/20241008-uvc-readless-v1-0-042ac4581f44@chromium.… --- Ricardo Ribalda (2): media: uvcvideo: Support partial control reads media: uvcvideo: Add more logging to uvc_query_ctrl() drivers/media/usb/uvc/uvc_video.c | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-) --- base-commit: 9852d85ec9d492ebef56dc5f229416c925758edc change-id: 20241008-uvc-readless-23f9b8cad0b3 Best regards, -- Ricardo Ribalda <ribalda(a)chromium.org>

7 months, 1 week

3
6
0 0

[PATCH] LoongArch: Explicitly specify code model in Makefile

by Huacai Chen

LoongArch's toolchain may change the default code model from normal to medium. This is unnecessary for kernel, and generates some relocations which cannot be handled by the module loader. So explicitly specify the code model to normal in Makefile (for Rust 'normal' is 'small'). Cc: stable(a)vger.kernel.org Tested-by: Haiyong Sun <sunhaiyong(a)loongson.cn> Signed-off-by: Huacai Chen <chenhuacai(a)loongson.cn> --- arch/loongarch/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/loongarch/Makefile b/arch/loongarch/Makefile index ae3f80622f4c..567bd122a9ee 100644 --- a/arch/loongarch/Makefile +++ b/arch/loongarch/Makefile @@ -59,7 +59,7 @@ endif ifdef CONFIG_64BIT ld-emul = $(64bit-emul) -cflags-y += -mabi=lp64s +cflags-y += -mabi=lp64s -mcmodel=normal endif cflags-y += -pipe $(CC_FLAGS_NO_FPU) @@ -104,7 +104,7 @@ ifdef CONFIG_OBJTOOL KBUILD_CFLAGS += -fno-jump-tables endif -KBUILD_RUSTFLAGS += --target=loongarch64-unknown-none-softfloat +KBUILD_RUSTFLAGS += --target=loongarch64-unknown-none-softfloat -Ccode-model=small KBUILD_RUSTFLAGS_KERNEL += -Zdirect-access-external-data=yes KBUILD_RUSTFLAGS_MODULE += -Zdirect-access-external-data=no -- 2.43.5

7 months, 1 week

1
0
0 0

Re: [PATCH 6.11 000/107] 6.11.10-rc1 review

by Ronald Warsow

Hi Greg no regressions here on x86_64 (RKL, Intel 11th Gen. CPU) Thanks Tested-by: Ronald Warsow <rwarsow(a)gmx.de>

7 months, 1 week

1
0
0 0

[PATCH AUTOSEL 4.19] ARM: 9434/1: cfi: Fix compilation corner case

by Sasha Levin

From: Linus Walleij <linus.walleij(a)linaro.org> [ Upstream commit 4aea16b7cfb76bd3361858ceee6893ef5c9b5570 ] When enabling expert mode CONFIG_EXPERT and using that power user mode to disable the branch prediction hardening !CONFIG_HARDEN_BRANCH_PREDICTOR, the assembly linker in CLANG notices that some assembly in proc-v7.S does not have corresponding C call sites, i.e. the prototypes in proc-v7-bugs.c are enclosed in ifdef CONFIG_HARDEN_BRANCH_PREDICTOR so this assembly: SYM_TYPED_FUNC_START(cpu_v7_smc_switch_mm) SYM_TYPED_FUNC_START(cpu_v7_hvc_switch_mm) Results in: ld.lld: error: undefined symbol: __kcfi_typeid_cpu_v7_smc_switch_mm >>> referenced by proc-v7.S:94 (.../arch/arm/mm/proc-v7.S:94) >>> arch/arm/mm/proc-v7.o:(.text+0x108) in archive vmlinux.a ld.lld: error: undefined symbol: __kcfi_typeid_cpu_v7_hvc_switch_mm >>> referenced by proc-v7.S:105 (.../arch/arm/mm/proc-v7.S:105) >>> arch/arm/mm/proc-v7.o:(.text+0x124) in archive vmlinux.a Fix this by adding an additional requirement that CONFIG_HARDEN_BRANCH_PREDICTOR has to be enabled to compile these assembly calls. Closes: https://lore.kernel.org/oe-kbuild-all/202411041456.ZsoEiD7T-lkp@intel.com/ Reported-by: kernel test robot <lkp(a)intel.com> Reviewed-by: Nathan Chancellor <nathan(a)kernel.org> Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> Signed-off-by: Russell King (Oracle) <rmk+kernel(a)armlinux.org.uk> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- arch/arm/mm/proc-v7.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S index e351d682c2e36..8bde80b31a861 100644 --- a/arch/arm/mm/proc-v7.S +++ b/arch/arm/mm/proc-v7.S @@ -94,7 +94,7 @@ ENTRY(cpu_v7_dcache_clean_area) ret lr ENDPROC(cpu_v7_dcache_clean_area) -#ifdef CONFIG_ARM_PSCI +#if defined(CONFIG_ARM_PSCI) && defined(CONFIG_HARDEN_BRANCH_PREDICTOR) .arch_extension sec ENTRY(cpu_v7_smc_switch_mm) stmfd sp!, {r0 - r3} -- 2.43.0

7 months, 1 week

1
0
0 0

[PATCH AUTOSEL 5.4 1/2] ARM: 9434/1: cfi: Fix compilation corner case

by Sasha Levin

From: Linus Walleij <linus.walleij(a)linaro.org> [ Upstream commit 4aea16b7cfb76bd3361858ceee6893ef5c9b5570 ] When enabling expert mode CONFIG_EXPERT and using that power user mode to disable the branch prediction hardening !CONFIG_HARDEN_BRANCH_PREDICTOR, the assembly linker in CLANG notices that some assembly in proc-v7.S does not have corresponding C call sites, i.e. the prototypes in proc-v7-bugs.c are enclosed in ifdef CONFIG_HARDEN_BRANCH_PREDICTOR so this assembly: SYM_TYPED_FUNC_START(cpu_v7_smc_switch_mm) SYM_TYPED_FUNC_START(cpu_v7_hvc_switch_mm) Results in: ld.lld: error: undefined symbol: __kcfi_typeid_cpu_v7_smc_switch_mm >>> referenced by proc-v7.S:94 (.../arch/arm/mm/proc-v7.S:94) >>> arch/arm/mm/proc-v7.o:(.text+0x108) in archive vmlinux.a ld.lld: error: undefined symbol: __kcfi_typeid_cpu_v7_hvc_switch_mm >>> referenced by proc-v7.S:105 (.../arch/arm/mm/proc-v7.S:105) >>> arch/arm/mm/proc-v7.o:(.text+0x124) in archive vmlinux.a Fix this by adding an additional requirement that CONFIG_HARDEN_BRANCH_PREDICTOR has to be enabled to compile these assembly calls. Closes: https://lore.kernel.org/oe-kbuild-all/202411041456.ZsoEiD7T-lkp@intel.com/ Reported-by: kernel test robot <lkp(a)intel.com> Reviewed-by: Nathan Chancellor <nathan(a)kernel.org> Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> Signed-off-by: Russell King (Oracle) <rmk+kernel(a)armlinux.org.uk> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- arch/arm/mm/proc-v7.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S index 48e0ef6f0dccf..aee85fd261f5d 100644 --- a/arch/arm/mm/proc-v7.S +++ b/arch/arm/mm/proc-v7.S @@ -91,7 +91,7 @@ ENTRY(cpu_v7_dcache_clean_area) ret lr ENDPROC(cpu_v7_dcache_clean_area) -#ifdef CONFIG_ARM_PSCI +#if defined(CONFIG_ARM_PSCI) && defined(CONFIG_HARDEN_BRANCH_PREDICTOR) .arch_extension sec ENTRY(cpu_v7_smc_switch_mm) stmfd sp!, {r0 - r3} -- 2.43.0

7 months, 1 week

1
1
0 0

[PATCH AUTOSEL 5.10 1/3] ALSA: usb-audio: Fix Yamaha P-125 Quirk Entry

by Sasha Levin

From: Eryk Zagorski <erykzagorski(a)gmail.com> [ Upstream commit 6f891ca15b017707840c9e7f5afd9fc6cfd7d8b1 ] This patch switches the P-125 quirk entry to use a composite quirk as the P-125 supplies both MIDI and Audio like many of the other Yamaha keyboards Signed-off-by: Eryk Zagorski <erykzagorski(a)gmail.com> Link: https://patch.msgid.link/20241111164520.9079-2-erykzagorski@gmail.com Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/usb/quirks-table.h | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/sound/usb/quirks-table.h b/sound/usb/quirks-table.h index c6104523dd79c..119c0bde74464 100644 --- a/sound/usb/quirks-table.h +++ b/sound/usb/quirks-table.h @@ -350,7 +350,6 @@ YAMAHA_DEVICE(0x105a, NULL), YAMAHA_DEVICE(0x105b, NULL), YAMAHA_DEVICE(0x105c, NULL), YAMAHA_DEVICE(0x105d, NULL), -YAMAHA_DEVICE(0x1718, "P-125"), { USB_DEVICE(0x0499, 0x1503), .driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) { @@ -485,6 +484,19 @@ YAMAHA_DEVICE(0x1718, "P-125"), } } }, +{ + USB_DEVICE(0x0499, 0x1718), + QUIRK_DRIVER_INFO { + /* .vendor_name = "Yamaha", */ + /* .product_name = "P-125", */ + QUIRK_DATA_COMPOSITE { + { QUIRK_DATA_STANDARD_AUDIO(1) }, + { QUIRK_DATA_STANDARD_AUDIO(2) }, + { QUIRK_DATA_MIDI_YAMAHA(3) }, + QUIRK_COMPOSITE_END + } + } +}, YAMAHA_DEVICE(0x2000, "DGP-7"), YAMAHA_DEVICE(0x2001, "DGP-5"), YAMAHA_DEVICE(0x2002, NULL), -- 2.43.0

7 months, 1 week

1
2
0 0

[PATCH AUTOSEL 5.15 1/4] ALSA: usb-audio: Fix Yamaha P-125 Quirk Entry

by Sasha Levin

From: Eryk Zagorski <erykzagorski(a)gmail.com> [ Upstream commit 6f891ca15b017707840c9e7f5afd9fc6cfd7d8b1 ] This patch switches the P-125 quirk entry to use a composite quirk as the P-125 supplies both MIDI and Audio like many of the other Yamaha keyboards Signed-off-by: Eryk Zagorski <erykzagorski(a)gmail.com> Link: https://patch.msgid.link/20241111164520.9079-2-erykzagorski@gmail.com Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/usb/quirks-table.h | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/sound/usb/quirks-table.h b/sound/usb/quirks-table.h index dd98b4e13edac..4690b44987c05 100644 --- a/sound/usb/quirks-table.h +++ b/sound/usb/quirks-table.h @@ -350,7 +350,6 @@ YAMAHA_DEVICE(0x105a, NULL), YAMAHA_DEVICE(0x105b, NULL), YAMAHA_DEVICE(0x105c, NULL), YAMAHA_DEVICE(0x105d, NULL), -YAMAHA_DEVICE(0x1718, "P-125"), { USB_DEVICE(0x0499, 0x1503), .driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) { @@ -485,6 +484,19 @@ YAMAHA_DEVICE(0x1718, "P-125"), } } }, +{ + USB_DEVICE(0x0499, 0x1718), + QUIRK_DRIVER_INFO { + /* .vendor_name = "Yamaha", */ + /* .product_name = "P-125", */ + QUIRK_DATA_COMPOSITE { + { QUIRK_DATA_STANDARD_AUDIO(1) }, + { QUIRK_DATA_STANDARD_AUDIO(2) }, + { QUIRK_DATA_MIDI_YAMAHA(3) }, + QUIRK_COMPOSITE_END + } + } +}, YAMAHA_DEVICE(0x2000, "DGP-7"), YAMAHA_DEVICE(0x2001, "DGP-5"), YAMAHA_DEVICE(0x2002, NULL), -- 2.43.0

7 months, 1 week

1
3
0 0

[PATCH AUTOSEL 6.11 01/10] integrity: Use static_assert() to check struct sizes

by Sasha Levin

From: "Gustavo A. R. Silva" <gustavoars(a)kernel.org> [ Upstream commit 08ae3e5f5fc8edb9bd0c7ef9696ff29ef18b26ef ] Commit 38aa3f5ac6d2 ("integrity: Avoid -Wflex-array-member-not-at-end warnings") introduced tagged `struct evm_ima_xattr_data_hdr` and `struct ima_digest_data_hdr`. We want to ensure that when new members need to be added to the flexible structures, they are always included within these tagged structs. So, we use `static_assert()` to ensure that the memory layout for both the flexible structure and the tagged struct is the same after any changes. Signed-off-by: Gustavo A. R. Silva <gustavoars(a)kernel.org> Tested-by: Roberto Sassu <roberto.sassu(a)huawei.com> Reviewed-by: Roberto Sassu <roberto.sassu(a)huawei.com> Signed-off-by: Mimi Zohar <zohar(a)linux.ibm.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- security/integrity/integrity.h | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/security/integrity/integrity.h b/security/integrity/integrity.h index 660f76cb69d37..c2c2da6911233 100644 --- a/security/integrity/integrity.h +++ b/security/integrity/integrity.h @@ -37,6 +37,8 @@ struct evm_ima_xattr_data { ); u8 data[]; } __packed; +static_assert(offsetof(struct evm_ima_xattr_data, data) == sizeof(struct evm_ima_xattr_data_hdr), + "struct member likely outside of __struct_group()"); /* Only used in the EVM HMAC code. */ struct evm_xattr { @@ -65,6 +67,8 @@ struct ima_digest_data { ); u8 digest[]; } __packed; +static_assert(offsetof(struct ima_digest_data, digest) == sizeof(struct ima_digest_data_hdr), + "struct member likely outside of __struct_group()"); /* * Instead of wrapping the ima_digest_data struct inside a local structure -- 2.43.0

7 months, 1 week

1
9
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror November 2024