From: Greg Kroah-Hartman Date: Mon, 13 Oct 2025 12:01:50 +0000 (+0200) Subject: 5.4-stable patches X-Git-Tag: v6.1.156~16 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=04a55fca56853a4284c822def10856d1b0dedc2a;p=thirdparty%2Fkernel%2Fstable-queue.git 5.4-stable patches added patches: input-uinput-zero-initialize-uinput_ff_upload_compat-to-avoid-info-leak.patch mm-hugetlb-avoid-soft-lockup-when-mprotect-to-large-memory-area.patch pinctrl-check-the-return-value-of-pinmux_ops-get_function_name.patch --- diff --git a/queue-5.4/input-uinput-zero-initialize-uinput_ff_upload_compat-to-avoid-info-leak.patch b/queue-5.4/input-uinput-zero-initialize-uinput_ff_upload_compat-to-avoid-info-leak.patch new file mode 100644 index 0000000000..6ba9d1ed15 --- /dev/null +++ b/queue-5.4/input-uinput-zero-initialize-uinput_ff_upload_compat-to-avoid-info-leak.patch @@ -0,0 +1,37 @@ +From d3366a04770eea807f2826cbdb96934dd8c9bf79 Mon Sep 17 00:00:00 2001 +From: Zhen Ni +Date: Sun, 28 Sep 2025 14:37:37 +0800 +Subject: Input: uinput - zero-initialize uinput_ff_upload_compat to avoid info leak + +From: Zhen Ni + +commit d3366a04770eea807f2826cbdb96934dd8c9bf79 upstream. + +Struct ff_effect_compat is embedded twice inside +uinput_ff_upload_compat, contains internal padding. In particular, there +is a hole after struct ff_replay to satisfy alignment requirements for +the following union member. Without clearing the structure, +copy_to_user() may leak stack data to userspace. + +Initialize ff_up_compat to zero before filling valid fields. + +Fixes: 2d56f3a32c0e ("Input: refactor evdev 32bit compat to be shareable with uinput") +Cc: stable@vger.kernel.org +Signed-off-by: Zhen Ni +Link: https://lore.kernel.org/r/20250928063737.74590-1-zhen.ni@easystack.cn +Signed-off-by: Dmitry Torokhov +Signed-off-by: Greg Kroah-Hartman +--- + drivers/input/misc/uinput.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/input/misc/uinput.c ++++ b/drivers/input/misc/uinput.c +@@ -740,6 +740,7 @@ static int uinput_ff_upload_to_user(char + if (in_compat_syscall()) { + struct uinput_ff_upload_compat ff_up_compat; + ++ memset(&ff_up_compat, 0, sizeof(ff_up_compat)); + ff_up_compat.request_id = ff_up->request_id; + ff_up_compat.retval = ff_up->retval; + /* diff --git a/queue-5.4/mm-hugetlb-avoid-soft-lockup-when-mprotect-to-large-memory-area.patch b/queue-5.4/mm-hugetlb-avoid-soft-lockup-when-mprotect-to-large-memory-area.patch new file mode 100644 index 0000000000..acb9d654ee --- /dev/null +++ b/queue-5.4/mm-hugetlb-avoid-soft-lockup-when-mprotect-to-large-memory-area.patch @@ -0,0 +1,88 @@ +From f52ce0ea90c83a28904c7cc203a70e6434adfecb Mon Sep 17 00:00:00 2001 +From: Yang Shi +Date: Mon, 29 Sep 2025 13:24:02 -0700 +Subject: mm: hugetlb: avoid soft lockup when mprotect to large memory area +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Yang Shi + +commit f52ce0ea90c83a28904c7cc203a70e6434adfecb upstream. + +When calling mprotect() to a large hugetlb memory area in our customer's +workload (~300GB hugetlb memory), soft lockup was observed: + +watchdog: BUG: soft lockup - CPU#98 stuck for 23s! [t2_new_sysv:126916] + +CPU: 98 PID: 126916 Comm: t2_new_sysv Kdump: loaded Not tainted 6.17-rc7 +Hardware name: GIGACOMPUTING R2A3-T40-AAV1/Jefferson CIO, BIOS 5.4.4.1 07/15/2025 +pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) +pc : mte_clear_page_tags+0x14/0x24 +lr : mte_sync_tags+0x1c0/0x240 +sp : ffff80003150bb80 +x29: ffff80003150bb80 x28: ffff00739e9705a8 x27: 0000ffd2d6a00000 +x26: 0000ff8e4bc00000 x25: 00e80046cde00f45 x24: 0000000000022458 +x23: 0000000000000000 x22: 0000000000000004 x21: 000000011b380000 +x20: ffff000000000000 x19: 000000011b379f40 x18: 0000000000000000 +x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 +x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 +x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc875e0aa5e2c +x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 +x5 : fffffc01ce7a5c00 x4 : 00000000046cde00 x3 : fffffc0000000000 +x2 : 0000000000000004 x1 : 0000000000000040 x0 : ffff0046cde7c000 + +Call trace: +  mte_clear_page_tags+0x14/0x24 +  set_huge_pte_at+0x25c/0x280 +  hugetlb_change_protection+0x220/0x430 +  change_protection+0x5c/0x8c +  mprotect_fixup+0x10c/0x294 +  do_mprotect_pkey.constprop.0+0x2e0/0x3d4 +  __arm64_sys_mprotect+0x24/0x44 +  invoke_syscall+0x50/0x160 +  el0_svc_common+0x48/0x144 +  do_el0_svc+0x30/0xe0 +  el0_svc+0x30/0xf0 +  el0t_64_sync_handler+0xc4/0x148 +  el0t_64_sync+0x1a4/0x1a8 + +Soft lockup is not triggered with THP or base page because there is +cond_resched() called for each PMD size. + +Although the soft lockup was triggered by MTE, it should be not MTE +specific. The other processing which takes long time in the loop may +trigger soft lockup too. + +So add cond_resched() for hugetlb to avoid soft lockup. + +Link: https://lkml.kernel.org/r/20250929202402.1663290-1-yang@os.amperecomputing.com +Fixes: 8f860591ffb2 ("[PATCH] Enable mprotect on huge pages") +Signed-off-by: Yang Shi +Tested-by: Carl Worth +Reviewed-by: Christoph Lameter (Ampere) +Reviewed-by: Catalin Marinas +Acked-by: David Hildenbrand +Acked-by: Oscar Salvador +Reviewed-by: Anshuman Khandual +Reviewed-by: Dev Jain +Cc: Muchun Song +Cc: Will Deacon +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + mm/hugetlb.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/mm/hugetlb.c ++++ b/mm/hugetlb.c +@@ -4703,6 +4703,8 @@ unsigned long hugetlb_change_protection( + pages++; + } + spin_unlock(ptl); ++ ++ cond_resched(); + } + /* + * Must flush TLB before releasing i_mmap_rwsem: x86's huge_pmd_unshare diff --git a/queue-5.4/pinctrl-check-the-return-value-of-pinmux_ops-get_function_name.patch b/queue-5.4/pinctrl-check-the-return-value-of-pinmux_ops-get_function_name.patch new file mode 100644 index 0000000000..cd4bb8fc2e --- /dev/null +++ b/queue-5.4/pinctrl-check-the-return-value-of-pinmux_ops-get_function_name.patch @@ -0,0 +1,37 @@ +From 4002ee98c022d671ecc1e4a84029e9ae7d8a5603 Mon Sep 17 00:00:00 2001 +From: Bartosz Golaszewski +Date: Tue, 2 Sep 2025 13:59:10 +0200 +Subject: pinctrl: check the return value of pinmux_ops::get_function_name() + +From: Bartosz Golaszewski + +commit 4002ee98c022d671ecc1e4a84029e9ae7d8a5603 upstream. + +While the API contract in docs doesn't specify it explicitly, the +generic implementation of the get_function_name() callback from struct +pinmux_ops - pinmux_generic_get_function_name() - can fail and return +NULL. This is already checked in pinmux_check_ops() so add a similar +check in pinmux_func_name_to_selector() instead of passing the returned +pointer right down to strcmp() where the NULL can get dereferenced. This +is normal operation when adding new pinfunctions. + +Cc: stable@vger.kernel.org +Tested-by: Neil Armstrong +Signed-off-by: Bartosz Golaszewski +Signed-off-by: Linus Walleij +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pinctrl/pinmux.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/pinctrl/pinmux.c ++++ b/drivers/pinctrl/pinmux.c +@@ -324,7 +324,7 @@ static int pinmux_func_name_to_selector( + while (selector < nfuncs) { + const char *fname = ops->get_function_name(pctldev, selector); + +- if (!strcmp(function, fname)) ++ if (fname && !strcmp(function, fname)) + return selector; + + selector++; diff --git a/queue-5.4/series b/queue-5.4/series index 16eb552257..e621a61772 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -72,3 +72,6 @@ net-ena-return-0-in-ena_get_rxfh_key_size-when-rss-h.patch revert-net-mlx5e-update-and-set-xon-xoff-upon-mtu-se.patch squashfs-fix-uninit-value-in-squashfs_get_parent.patch uio_hv_generic-let-userspace-take-care-of-interrupt-mask.patch +mm-hugetlb-avoid-soft-lockup-when-mprotect-to-large-memory-area.patch +input-uinput-zero-initialize-uinput_ff_upload_compat-to-avoid-info-leak.patch +pinctrl-check-the-return-value-of-pinmux_ops-get_function_name.patch