user/sven/linux.git, branch v6.6.59

Linux 6.6.59

2024-11-01T00:58:34Z

Link: https://lore.kernel.org/r/20241028062306.649733554@linuxfoundation.org Tested-by: Miguel Ojeda Tested-by: Takeshi Ogasawara Tested-by: Mark Brown Tested-by: Linux Kernel Functional Testing Tested-by: SeongJae Park Tested-by: Peter Schneider Tested-by: Florian Fainelli Tested-by: Hardik Garg Tested-by: Harshit Mogalapalli Tested-by: kernelci.org bot Tested-by: Ron Economos Signed-off-by: Greg Kroah-Hartman

xfrm: validate new SA's prefixlen using SA family when sel.family is unset

2024-11-01T00:58:34Z

[ Upstream commit 3f0ab59e6537c6a8f9e1b355b48f9c05a76e8563 ] This expands the validation introduced in commit 07bf7908950a ("xfrm: Validate address prefix lengths in the xfrm selector.") syzbot created an SA with usersa.sel.family = AF_UNSPEC usersa.sel.prefixlen_s = 128 usersa.family = AF_INET Because of the AF_UNSPEC selector, verify_newsa_info doesn't put limits on prefixlen_{s,d}. But then copy_from_user_state sets x->sel.family to usersa.family (AF_INET). Do the same conversion in verify_newsa_info before validating prefixlen_{s,d}, since that's how prefixlen is going to be used later on. Reported-by: syzbot+cc39f136925517aed571@syzkaller.appspotmail.com Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Sabrina Dubroca Signed-off-by: Steffen Klassert Signed-off-by: Antony Antony Signed-off-by: Sasha Levin

task_work: make TWA_NMI_CURRENT handling conditional on IRQ_WORK

2024-11-01T00:58:34Z

commit cec6937dd1aae1b38d147bd190cb895d06cf96d0 upstream. The TWA_NMI_CURRENT handling very much depends on IRQ_WORK, but that isn't universally enabled everywhere. Maybe the IRQ_WORK infrastructure should just be unconditional - x86 ends up indirectly enabling it through unconditionally enabling PERF_EVENTS, for example. But it also gets enabled by having SMP support, or even if you just have PRINTK enabled. But in the meantime TWA_NMI_CURRENT causes tons of build failures on various odd minimal configs. Which did show up in linux-next, but despite that nobody bothered to fix it or even inform me until -rc1 was out. Fixes: 466e4d801cd4 ("task_work: Add TWA_NMI_CURRENT as an additional notify mode") Reported-by: Naresh Kamboju Reported-by: kernelci.org bot Reported-by: Guenter Roeck Cc: Peter Zijlstra Cc: Sebastian Andrzej Siewior Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

tracing: probes: Fix to zero initialize a local variable

2024-11-01T00:58:34Z

commit 0add699ad068d26e5b1da9ff28b15461fc4005df upstream. Fix to initialize 'val' local variable with zero. Dan reported that Smatch static code checker reports an error that a local 'val' variable needs to be initialized. Actually, the 'val' is expected to be initialized by FETCH_OP_ARG in the same loop, but it is not obvious. So initialize it with zero. Link: https://lore.kernel.org/all/171092223833.237219.17304490075697026697.stgit@devnote2/ Reported-by: Dan Carpenter Closes: https://lore.kernel.org/all/b010488e-68aa-407c-add0-3e059254aaa0@moroto.mountain/ Fixes: 25f00e40ce79 ("tracing/probes: Support $argN in return probe (kprobe and fprobe)") Reviewed-by: Steven Rostedt (Google) Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Greg Kroah-Hartman

RDMA/bnxt_re: Fix unconditional fence for newer adapters

2024-11-01T00:58:34Z

commit 8eaca6b5997bd8fd7039f2693e4ecf112823c816 upstream. Older adapters required an unconditional fence for non-wire memory operations. Newer adapters doesn't require this and therefore, disabling the unconditional fence. Fixes: 1801d87b3598 ("RDMA/bnxt_re: Support new 5760X P7 devices") Signed-off-by: Kashyap Desai Signed-off-by: Kalesh AP Signed-off-by: Selvin Xavier Link: https://lore.kernel.org/r/1705985677-15551-4-git-send-email-selvin.xavier@broadcom.com Signed-off-by: Leon Romanovsky Signed-off-by: Greg Kroah-Hartman

RDMA/bnxt_re: Avoid creating fence MR for newer adapters

2024-11-01T00:58:34Z

commit 282fd66e2ef6e5d72b8fcd77efb2b282d2569464 upstream. Limit the usage of fence MR to adapters older than Gen P5 products. Fixes: 1801d87b3598 ("RDMA/bnxt_re: Support new 5760X P7 devices") Signed-off-by: Kashyap Desai Signed-off-by: Bhargava Chenna Marreddy Signed-off-by: Kalesh AP Signed-off-by: Selvin Xavier Link: https://lore.kernel.org/r/1705985677-15551-2-git-send-email-selvin.xavier@broadcom.com Signed-off-by: Leon Romanovsky Signed-off-by: Greg Kroah-Hartman

RDMA/bnxt_re: Fix the offset for GenP7 adapters for user applications

2024-11-01T00:58:34Z

commit 9248f363d0791a548a9c7711365b8be4c70bd375 upstream. User Doorbell page indexes start at an offset for GenP7 adapters. Fix the offset that will be used for user doorbell page indexes. Fixes: a62d68581441 ("RDMA/bnxt_re: Update the BAR offsets") Signed-off-by: Selvin Xavier Link: https://lore.kernel.org/r/1702987900-5363-1-git-send-email-selvin.xavier@broadcom.com Signed-off-by: Leon Romanovsky Signed-off-by: Greg Kroah-Hartman

ACPI: PRM: Clean up guid type in struct prm_handler_info

2024-11-01T00:58:34Z

commit 3d1c651272cf1df8aac7d9b6d92d836d27bed50f upstream. Clang 19 prints a warning when we pass &th->guid to efi_pa_va_lookup(): drivers/acpi/prmt.c:156:29: error: passing 1-byte aligned argument to 4-byte aligned parameter 1 of 'efi_pa_va_lookup' may result in an unaligned pointer access [-Werror,-Walign-mismatch] 156 | (void *)efi_pa_va_lookup(&th->guid, handler_info->handler_address); | ^ The problem is that efi_pa_va_lookup() takes a efi_guid_t and &th->guid is a regular guid_t. The difference between the two types is the alignment. efi_guid_t is a typedef. typedef guid_t efi_guid_t __aligned(__alignof__(u32)); It's possible that this a bug in Clang 19. Even though the alignment of &th->guid is not explicitly specified, it will still end up being aligned at 4 or 8 bytes. Anyway, as Ard points out, it's cleaner to change guid to efi_guid_t type and that also makes the warning go away. Fixes: 088984c8d54c ("ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context") Reported-by: Linux Kernel Functional Testing Suggested-by: Ard Biesheuvel Signed-off-by: Dan Carpenter Tested-by: Paul E. McKenney Acked-by: Ard Biesheuvel Link: https://patch.msgid.link/3777d71b-9e19-45f4-be4e-17bf4fa7a834@stanley.mountain [ rjw: Subject edit ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

platform/x86: dell-wmi: Ignore suspend notifications

2024-11-01T00:58:34Z

commit a7990957fa53326fe9b47f0349373ed99bb69aaa upstream. Some machines like the Dell G15 5155 emit WMI events when suspending/resuming. Ignore those WMI events. Tested-by: siddharth.manthan@gmail.com Signed-off-by: Armin Wolf Acked-by: Pali Rohár Link: https://lore.kernel.org/r/20241014220529.397390-1-W_Armin@gmx.de Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman

ASoC: qcom: Fix NULL Dereference in asoc_qcom_lpass_cpu_platform_probe()

2024-11-01T00:58:34Z

commit 49da1463c9e3d2082276c3e0e2a8b65a88711cd2 upstream. A devm_kzalloc() in asoc_qcom_lpass_cpu_platform_probe() could possibly return NULL pointer. NULL Pointer Dereference may be triggerred without addtional check. Add a NULL check for the returned pointer. Fixes: b5022a36d28f ("ASoC: qcom: lpass: Use regmap_field for i2sctl and dmactl registers") Cc: stable@vger.kernel.org Signed-off-by: Zichen Xie Link: https://patch.msgid.link/20241006205737.8829-1-zichenxie0106@gmail.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman