From nobody Tue Apr 28 06:24:51 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8B4B0C433EF for ; Fri, 3 Jun 2022 17:48:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345244AbiFCRsJ (ORCPT ); Fri, 3 Jun 2022 13:48:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46572 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345149AbiFCRr5 (ORCPT ); Fri, 3 Jun 2022 13:47:57 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6E6785715E; Fri, 3 Jun 2022 10:44:25 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 99EB5B823B0; Fri, 3 Jun 2022 17:44:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E82AFC385A9; Fri, 3 Jun 2022 17:44:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278262; bh=p2Kw4t5xphJd3kFvMz9xTPiah3ar/k3FK8fFR1qbuXY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=luBBs7ikW4Ot6JcBvUfYct4uIVUJkkqQkQb53eDNw/F/td/szFZuX+t9sqfwj/Tla lKyJsgCDuGw1oDZynxBwAa5vpc0++CccOa7wulm6CLCC3Ub7oRB6/PrW01/oFPpe42 qlMq2E0/Hsr1+hq9T9Qpl9TivlSRBN7zxTYf1Nxk= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Stephen Brennan , Douglas Anderson , Daniel Thompson , Linus Torvalds Subject: [PATCH 5.4 01/34] lockdown: also lock down previous kgdb use Date: Fri, 3 Jun 2022 19:42:57 +0200 Message-Id: <20220603173816.035183151@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173815.990072516@linuxfoundation.org> References: <20220603173815.990072516@linuxfoundation.org> User-Agent: quilt/0.66 X-stable: review X-Patchwork-Hint: ignore MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Daniel Thompson commit eadb2f47a3ced5c64b23b90fd2a3463f63726066 upstream. KGDB and KDB allow read and write access to kernel memory, and thus should be restricted during lockdown. An attacker with access to a serial port (for example, via a hypervisor console, which some cloud vendors provide over the network) could trigger the debugger so it is important that the debugger respect the lockdown mode when/if it is triggered. Fix this by integrating lockdown into kdb's existing permissions mechanism. Unfortunately kgdb does not have any permissions mechanism (although it certainly could be added later) so, for now, kgdb is simply and brutally disabled by immediately exiting the gdb stub without taking any action. For lockdowns established early in the boot (e.g. the normal case) then this should be fine but on systems where kgdb has set breakpoints before the lockdown is enacted than "bad things" will happen. CVE: CVE-2022-21499 Co-developed-by: Stephen Brennan Signed-off-by: Stephen Brennan Reviewed-by: Douglas Anderson Signed-off-by: Daniel Thompson Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee --- include/linux/security.h | 2 + kernel/debug/debug_core.c | 24 ++++++++++++++++ kernel/debug/kdb/kdb_main.c | 62 ++++++++++++++++++++++++++++++++++++++= ++--- security/lockdown/lockdown.c | 2 + 4 files changed, 87 insertions(+), 3 deletions(-) --- a/include/linux/security.h +++ b/include/linux/security.h @@ -118,10 +118,12 @@ enum lockdown_reason { LOCKDOWN_MMIOTRACE, LOCKDOWN_DEBUGFS, LOCKDOWN_XMON_WR, + LOCKDOWN_DBG_WRITE_KERNEL, LOCKDOWN_INTEGRITY_MAX, LOCKDOWN_KCORE, LOCKDOWN_KPROBES, LOCKDOWN_BPF_READ, + LOCKDOWN_DBG_READ_KERNEL, LOCKDOWN_PERF, LOCKDOWN_TRACEFS, LOCKDOWN_XMON_RW, --- a/kernel/debug/debug_core.c +++ b/kernel/debug/debug_core.c @@ -56,6 +56,7 @@ #include #include #include +#include =20 #include #include @@ -685,6 +686,29 @@ cpu_master_loop: continue; kgdb_connected =3D 0; } else { + /* + * This is a brutal way to interfere with the debugger + * and prevent gdb being used to poke at kernel memory. + * This could cause trouble if lockdown is applied when + * there is already an active gdb session. For now the + * answer is simply "don't do that". Typically lockdown + * *will* be applied before the debug core gets started + * so only developers using kgdb for fairly advanced + * early kernel debug can be biten by this. Hopefully + * they are sophisticated enough to take care of + * themselves, especially with help from the lockdown + * message printed on the console! + */ + if (security_locked_down(LOCKDOWN_DBG_WRITE_KERNEL)) { + if (IS_ENABLED(CONFIG_KGDB_KDB)) { + /* Switch back to kdb if possible... */ + dbg_kdb_mode =3D 1; + continue; + } else { + /* ... otherwise just bail */ + break; + } + } error =3D gdb_serial_stub(ks); } =20 --- a/kernel/debug/kdb/kdb_main.c +++ b/kernel/debug/kdb/kdb_main.c @@ -45,6 +45,7 @@ #include #include #include +#include #include "kdb_private.h" =20 #undef MODULE_PARAM_PREFIX @@ -198,10 +199,62 @@ struct task_struct *kdb_curr_task(int cp } =20 /* - * Check whether the flags of the current command and the permissions - * of the kdb console has allow a command to be run. + * Update the permissions flags (kdb_cmd_enabled) to match the + * current lockdown state. + * + * Within this function the calls to security_locked_down() are "lazy". We + * avoid calling them if the current value of kdb_cmd_enabled already excl= udes + * flags that might be subject to lockdown. Additionally we deliberately c= heck + * the lockdown flags independently (even though read lockdown implies wri= te + * lockdown) since that results in both simpler code and clearer messages = to + * the user on first-time debugger entry. + * + * The permission masks during a read+write lockdown permits the following + * flags: INSPECT, SIGNAL, REBOOT (and ALWAYS_SAFE). + * + * The INSPECT commands are not blocked during lockdown because they are + * not arbitrary memory reads. INSPECT covers the backtrace family (someti= mes + * forcing them to have no arguments) and lsmod. These commands do expose + * some kernel state but do not allow the developer seated at the console = to + * choose what state is reported. SIGNAL and REBOOT should not be controve= rsial, + * given these are allowed for root during lockdown already. + */ +static void kdb_check_for_lockdown(void) +{ + const int write_flags =3D KDB_ENABLE_MEM_WRITE | + KDB_ENABLE_REG_WRITE | + KDB_ENABLE_FLOW_CTRL; + const int read_flags =3D KDB_ENABLE_MEM_READ | + KDB_ENABLE_REG_READ; + + bool need_to_lockdown_write =3D false; + bool need_to_lockdown_read =3D false; + + if (kdb_cmd_enabled & (KDB_ENABLE_ALL | write_flags)) + need_to_lockdown_write =3D + security_locked_down(LOCKDOWN_DBG_WRITE_KERNEL); + + if (kdb_cmd_enabled & (KDB_ENABLE_ALL | read_flags)) + need_to_lockdown_read =3D + security_locked_down(LOCKDOWN_DBG_READ_KERNEL); + + /* De-compose KDB_ENABLE_ALL if required */ + if (need_to_lockdown_write || need_to_lockdown_read) + if (kdb_cmd_enabled & KDB_ENABLE_ALL) + kdb_cmd_enabled =3D KDB_ENABLE_MASK & ~KDB_ENABLE_ALL; + + if (need_to_lockdown_write) + kdb_cmd_enabled &=3D ~write_flags; + + if (need_to_lockdown_read) + kdb_cmd_enabled &=3D ~read_flags; +} + +/* + * Check whether the flags of the current command, the permissions of the = kdb + * console and the lockdown state allow a command to be run. */ -static inline bool kdb_check_flags(kdb_cmdflags_t flags, int permissions, +static bool kdb_check_flags(kdb_cmdflags_t flags, int permissions, bool no_args) { /* permissions comes from userspace so needs massaging slightly */ @@ -1188,6 +1241,9 @@ static int kdb_local(kdb_reason_t reason kdb_curr_task(raw_smp_processor_id()); =20 KDB_DEBUG_STATE("kdb_local 1", reason); + + kdb_check_for_lockdown(); + kdb_go_count =3D 0; if (reason =3D=3D KDB_REASON_DEBUG) { /* special case below */ --- a/security/lockdown/lockdown.c +++ b/security/lockdown/lockdown.c @@ -33,10 +33,12 @@ static const char *const lockdown_reason [LOCKDOWN_MMIOTRACE] =3D "unsafe mmio", [LOCKDOWN_DEBUGFS] =3D "debugfs access", [LOCKDOWN_XMON_WR] =3D "xmon write access", + [LOCKDOWN_DBG_WRITE_KERNEL] =3D "use of kgdb/kdb to write kernel RAM", [LOCKDOWN_INTEGRITY_MAX] =3D "integrity", [LOCKDOWN_KCORE] =3D "/proc/kcore access", [LOCKDOWN_KPROBES] =3D "use of kprobes", [LOCKDOWN_BPF_READ] =3D "use of bpf to read kernel RAM", + [LOCKDOWN_DBG_READ_KERNEL] =3D "use of kgdb/kdb to read kernel RAM", [LOCKDOWN_PERF] =3D "unsafe use of perf", [LOCKDOWN_TRACEFS] =3D "use of tracefs", [LOCKDOWN_XMON_RW] =3D "xmon read and write access", From nobody Tue Apr 28 06:24:51 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8055AC433EF for ; Fri, 3 Jun 2022 17:48:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345295AbiFCRsv (ORCPT ); Fri, 3 Jun 2022 13:48:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46612 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242471AbiFCRsB (ORCPT ); Fri, 3 Jun 2022 13:48:01 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DF61657114; Fri, 3 Jun 2022 10:44:27 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 83F13B82433; Fri, 3 Jun 2022 17:44:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CA81EC3411E; Fri, 3 Jun 2022 17:44:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278265; bh=eAgeRX0XfrOtYG0LIdo5Tzi4tDG+++Ix0SbqivlBhe4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=IuGydQr+uF753CPS05b+kvUnygsd2mLb6FmiHXg0OoMmTngqsqRCJUfsn4Z/dGOZA rxvc4vaMdpYGJpu8kSc+9qVNGBolGCwBPPTtZwNnxLkzSbAYaCWZO4hx50vWTpswUq 2cRFW11enJqDNYLl3nefN9gSMFg+gCL9PTN03BP0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jeremi Piotrowski , Dusty Mabe , Salvatore Bonaccorso , Thomas Gleixner , Noah Meyerhans , Noah Meyerhans Subject: [PATCH 5.4 02/34] x86/pci/xen: Disable PCI/MSI[-X] masking for XEN_HVM guests Date: Fri, 3 Jun 2022 19:42:58 +0200 Message-Id: <20220603173816.063706442@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173815.990072516@linuxfoundation.org> References: <20220603173815.990072516@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Thomas Gleixner commit 7e0815b3e09986d2fe651199363e135b9358132a upstream. When a XEN_HVM guest uses the XEN PIRQ/Eventchannel mechanism, then PCI/MSI[-X] masking is solely controlled by the hypervisor, but contrary to XEN_PV guests this does not disable PCI/MSI[-X] masking in the PCI/MSI layer. This can lead to a situation where the PCI/MSI layer masks an MSI[-X] interrupt and the hypervisor grants the write despite the fact that it already requested the interrupt. As a consequence interrupt delivery on the affected device is not happening ever. Set pci_msi_ignore_mask to prevent that like it's done for XEN_PV guests already. Fixes: 809f9267bbab ("xen: map MSIs into pirqs") Reported-by: Jeremi Piotrowski Reported-by: Dusty Mabe Reported-by: Salvatore Bonaccorso Signed-off-by: Thomas Gleixner Tested-by: Noah Meyerhans Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/87tuaduxj5.ffs@tglx [nmeyerha@amazon.com: backported to 5.4] Signed-off-by: Noah Meyerhans Signed-off-by: Greg Kroah-Hartman Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee --- arch/x86/pci/xen.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/arch/x86/pci/xen.c +++ b/arch/x86/pci/xen.c @@ -442,6 +442,11 @@ void __init xen_msi_init(void) =20 x86_msi.setup_msi_irqs =3D xen_hvm_setup_msi_irqs; x86_msi.teardown_msi_irq =3D xen_teardown_msi_irq; + /* + * With XEN PIRQ/Eventchannels in use PCI/MSI[-X] masking is solely + * controlled by the hypervisor. + */ + pci_msi_ignore_mask =3D 1; } #endif From nobody Tue Apr 28 06:24:51 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DCD84C433EF for ; Fri, 3 Jun 2022 17:48:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345196AbiFCRsO (ORCPT ); Fri, 3 Jun 2022 13:48:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45560 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345251AbiFCRsD (ORCPT ); Fri, 3 Jun 2022 13:48:03 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A701357179; Fri, 3 Jun 2022 10:44:30 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 54F2FB82436; Fri, 3 Jun 2022 17:44:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BD5D4C385A9; Fri, 3 Jun 2022 17:44:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278268; bh=JwRn3piZByy6d3OEljMZ0zRxdm1NyDdxdF436yhUpcQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=j78zxaWy9mhr8NO8wkaIcl2FwAK1qpJVde/w7ZPgbgLYxHQxnxdUdGkl9wn8/KPtf iGnIHixFVYpDVfCk6KEPZWo0QpuOIZGW8rAtkCgCqAkVXiZVOW7NM8qOoJlJveU37t FB24kf3tWaB/BoRAhvOGpQGww1PRKVc6wjVOp/E8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, "Denis Efremov (Oracle)" Subject: [PATCH 5.4 03/34] staging: rtl8723bs: prevent ->Ssid overflow in rtw_wx_set_scan() Date: Fri, 3 Jun 2022 19:42:59 +0200 Message-Id: <20220603173816.091930554@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173815.990072516@linuxfoundation.org> References: <20220603173815.990072516@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: "Denis Efremov (Oracle)" This code has a check to prevent read overflow but it needs another check to prevent writing beyond the end of the ->Ssid[] array. Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver") Cc: stable Signed-off-by: Denis Efremov (Oracle) Signed-off-by: Greg Kroah-Hartman Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee --- drivers/staging/rtl8723bs/os_dep/ioctl_linux.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c +++ b/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c @@ -1351,9 +1351,11 @@ static int rtw_wx_set_scan(struct net_de =20 sec_len =3D *(pos++); len-=3D 1; =20 - if (sec_len>0 && sec_len<=3Dlen) { + if (sec_len > 0 && + sec_len <=3D len && + sec_len <=3D 32) { ssid[ssid_index].SsidLength =3D sec_len; - memcpy(ssid[ssid_index].Ssid, pos, ssid[ssid_index].SsidLength); + memcpy(ssid[ssid_index].Ssid, pos, sec_len); /* DBG_871X("%s COMBO_SCAN with specific ssid:%s, %d\n", __func__ */ /* , ssid[ssid_index].Ssid, ssid[ssid_index].SsidLength); */ ssid_index++; From nobody Tue Apr 28 06:24:51 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 50D89C433EF for ; Fri, 3 Jun 2022 17:48:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345307AbiFCRsq (ORCPT ); Fri, 3 Jun 2022 13:48:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45970 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345258AbiFCRsD (ORCPT ); Fri, 3 Jun 2022 13:48:03 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9400957994; Fri, 3 Jun 2022 10:44:32 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 8E5AC61B38; Fri, 3 Jun 2022 17:44:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9DD11C341C0; Fri, 3 Jun 2022 17:44:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278271; bh=atzWDr3Jf2Jp/XXbxcAVp3pEhbI+lZ1uviGA5cgwK2I=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ojoOvXXQOGMPpUtr9h7PR/gXZTbEWNZA/XQ8t5ejMu62jMPCZl+81QL73i/B8gypy E4zAkUMuxP1cnGKEgdYnVw+zIYziWlCkTBoAjwhqDHWI4H7X09uUR+R6I0hAsg9zJq Bu/yuxo1cQ0tCYg9MP9A3uHG1HUR4L1bekzJfXT4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Dmitry Mastykin , Bastien Nocera , Dmitry Torokhov , Fabio Estevam Subject: [PATCH 5.4 04/34] Input: goodix - fix spurious key release events Date: Fri, 3 Jun 2022 19:43:00 +0200 Message-Id: <20220603173816.122230068@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173815.990072516@linuxfoundation.org> References: <20220603173815.990072516@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Dmitry Mastykin commit 24ef83f6e31d20fc121a7cd732b04b498475fca3 upstream. The goodix panel sends spurious interrupts after a 'finger up' event, which always cause a timeout. We were exiting the interrupt handler by reporting touch_num =3D=3D 0, but this was still processed as valid and caused the code to use the uninitialised point_data, creating spurious key release events. Report an error from the interrupt handler so as to avoid processing invalid point_data further. Signed-off-by: Dmitry Mastykin Reviewed-by: Bastien Nocera Link: https://lore.kernel.org/r/20200316075302.3759-2-dmastykin@astralinux.= ru Signed-off-by: Dmitry Torokhov Cc: Fabio Estevam Signed-off-by: Greg Kroah-Hartman Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee --- drivers/input/touchscreen/goodix.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/input/touchscreen/goodix.c +++ b/drivers/input/touchscreen/goodix.c @@ -335,7 +335,7 @@ static int goodix_ts_read_input_report(s * The Goodix panel will send spurious interrupts after a * 'finger up' event, which will always cause a timeout. */ - return 0; + return -ENOMSG; } =20 static void goodix_ts_report_touch_8b(struct goodix_ts_data *ts, u8 *coor_= data) From nobody Tue Apr 28 06:24:51 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9EC34C433EF for ; Fri, 3 Jun 2022 17:48:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345189AbiFCRsS (ORCPT ); Fri, 3 Jun 2022 13:48:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46540 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345004AbiFCRsG (ORCPT ); Fri, 3 Jun 2022 13:48:06 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6E214579B6; Fri, 3 Jun 2022 10:44:36 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 1E6E0B823B0; Fri, 3 Jun 2022 17:44:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7E330C385B8; Fri, 3 Jun 2022 17:44:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278273; bh=311bfCw+p6Ifhva2ftAsh3+p6uETNMSRYcBZw1q//wg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=fFub/l9kOly7JU40N9a5U467RcDA4S3lUj2p5+iMKKgEAnLj4+z54NaUhLnps38c0 QG82ZMw1mIn44nFym07SipsoeI0Qay1KvEGtvvXFSh+3ldFk4SO/8k4fue1iaL7vyW vQFUhfzktuXGcUm09KNkEiTr0HIyuFs3aH7Ea5Mk= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Eric Dumazet , David Dworken , Willem de Bruijn , "David S. Miller" , Stefan Ghinea Subject: [PATCH 5.4 05/34] tcp: change source port randomizarion at connect() time Date: Fri, 3 Jun 2022 19:43:01 +0200 Message-Id: <20220603173816.151314434@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173815.990072516@linuxfoundation.org> References: <20220603173815.990072516@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Eric Dumazet commit 190cc82489f46f9d88e73c81a47e14f80a791e1a upstream. RFC 6056 (Recommendations for Transport-Protocol Port Randomization) provides good summary of why source selection needs extra care. David Dworken reminded us that linux implements Algorithm 3 as described in RFC 6056 3.3.3 Quoting David : In the context of the web, this creates an interesting info leak where websites can count how many TCP connections a user's computer is establishing over time. For example, this allows a website to count exactly how many subresources a third party website loaded. This also allows: - Distinguishing between different users behind a VPN based on distinct source port ranges. - Tracking users over time across multiple networks. - Covert communication channels between different browsers/browser profiles running on the same computer - Tracking what applications are running on a computer based on the pattern of how fast source ports are getting incremented. Section 3.3.4 describes an enhancement, that reduces attackers ability to use the basic information currently stored into the shared 'u32 hint'. This change also decreases collision rate when multiple applications need to connect() to different destinations. Signed-off-by: Eric Dumazet Reported-by: David Dworken Cc: Willem de Bruijn Signed-off-by: David S. Miller Signed-off-by: Stefan Ghinea Signed-off-by: Greg Kroah-Hartman Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee --- net/ipv4/inet_hashtables.c | 20 +++++++++++++++++--- 1 file changed, 17 insertions(+), 3 deletions(-) --- a/net/ipv4/inet_hashtables.c +++ b/net/ipv4/inet_hashtables.c @@ -671,6 +671,17 @@ unlock: } EXPORT_SYMBOL_GPL(inet_unhash); =20 +/* RFC 6056 3.3.4. Algorithm 4: Double-Hash Port Selection Algorithm + * Note that we use 32bit integers (vs RFC 'short integers') + * because 2^16 is not a multiple of num_ephemeral and this + * property might be used by clever attacker. + * RFC claims using TABLE_LENGTH=3D10 buckets gives an improvement, + * we use 256 instead to really give more isolation and + * privacy, this only consumes 1 KB of kernel memory. + */ +#define INET_TABLE_PERTURB_SHIFT 8 +static u32 table_perturb[1 << INET_TABLE_PERTURB_SHIFT]; + int __inet_hash_connect(struct inet_timewait_death_row *death_row, struct sock *sk, u32 port_offset, int (*check_established)(struct inet_timewait_death_row *, @@ -684,8 +695,8 @@ int __inet_hash_connect(struct inet_time struct inet_bind_bucket *tb; u32 remaining, offset; int ret, i, low, high; - static u32 hint; int l3mdev; + u32 index; =20 if (port) { head =3D &hinfo->bhash[inet_bhashfn(net, port, @@ -712,7 +723,10 @@ int __inet_hash_connect(struct inet_time if (likely(remaining > 1)) remaining &=3D ~1U; =20 - offset =3D (hint + port_offset) % remaining; + net_get_random_once(table_perturb, sizeof(table_perturb)); + index =3D hash_32(port_offset, INET_TABLE_PERTURB_SHIFT); + + offset =3D (READ_ONCE(table_perturb[index]) + port_offset) % remaining; /* In first pass we try ports of @low parity. * inet_csk_get_port() does the opposite choice. */ @@ -766,7 +780,7 @@ next_port: return -EADDRNOTAVAIL; =20 ok: - hint +=3D i + 2; + WRITE_ONCE(table_perturb[index], READ_ONCE(table_perturb[index]) + i + 2); =20 /* Head lock still held and bh's disabled */ inet_bind_hash(sk, tb, port); From nobody Tue Apr 28 06:24:51 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8CB22C433EF for ; Fri, 3 Jun 2022 17:48:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345276AbiFCRsg (ORCPT ); Fri, 3 Jun 2022 13:48:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46576 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345305AbiFCRsH (ORCPT ); Fri, 3 Jun 2022 13:48:07 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EEF1357B04; Fri, 3 Jun 2022 10:44:37 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 3B3BD61AD7; Fri, 3 Jun 2022 17:44:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 43F64C385A9; Fri, 3 Jun 2022 17:44:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278276; bh=Cx8j6TGNcfOGltVh+shM90sXuC6xABAuTb/pYwuK17Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=pdCAdSsW5XTKkN+Y1ds2ZnHEZu+zDa5e0K/Uhtl/ikeH/VH94EoWc0+i+68ITqdcV yyPtFFySYXW6lTKocvD4ORK+awp1hZ7azMqW4zrd7Nd4mlEqGYTP61SolyBsw9Ailj 7mmEu9DI7fhgypKpek8WQ0kV7F9cD2CG6ZOVAR0o= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, "Jason A. Donenfeld" , Moshe Kol , Yossi Gilad , Amit Klein , Eric Dumazet , Willy Tarreau , Jakub Kicinski , Stefan Ghinea Subject: [PATCH 5.4 06/34] secure_seq: use the 64 bits of the siphash for port offset calculation Date: Fri, 3 Jun 2022 19:43:02 +0200 Message-Id: <20220603173816.180109481@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173815.990072516@linuxfoundation.org> References: <20220603173815.990072516@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Willy Tarreau commit b2d057560b8107c633b39aabe517ff9d93f285e3 upstream. SipHash replaced MD5 in secure_ipv{4,6}_port_ephemeral() via commit 7cd23e5300c1 ("secure_seq: use SipHash in place of MD5"), but the output remained truncated to 32-bit only. In order to exploit more bits from the hash, let's make the functions return the full 64-bit of siphash_3u32(). We also make sure the port offset calculation in __inet_hash_connect() remains done on 32-bit to avoid the need for div_u64_rem() and an extra cost on 32-bit systems. Cc: Jason A. Donenfeld Cc: Moshe Kol Cc: Yossi Gilad Cc: Amit Klein Reviewed-by: Eric Dumazet Signed-off-by: Willy Tarreau Signed-off-by: Jakub Kicinski [SG: Adjusted context] Signed-off-by: Stefan Ghinea Signed-off-by: Greg Kroah-Hartman Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee --- include/net/inet_hashtables.h | 2 +- include/net/secure_seq.h | 4 ++-- net/core/secure_seq.c | 4 ++-- net/ipv4/inet_hashtables.c | 10 ++++++---- net/ipv6/inet6_hashtables.c | 4 ++-- 5 files changed, 13 insertions(+), 11 deletions(-) --- a/include/net/inet_hashtables.h +++ b/include/net/inet_hashtables.h @@ -420,7 +420,7 @@ static inline void sk_rcv_saddr_set(stru } =20 int __inet_hash_connect(struct inet_timewait_death_row *death_row, - struct sock *sk, u32 port_offset, + struct sock *sk, u64 port_offset, int (*check_established)(struct inet_timewait_death_row *, struct sock *, __u16, struct inet_timewait_sock **)); --- a/include/net/secure_seq.h +++ b/include/net/secure_seq.h @@ -4,8 +4,8 @@ =20 #include =20 -u32 secure_ipv4_port_ephemeral(__be32 saddr, __be32 daddr, __be16 dport); -u32 secure_ipv6_port_ephemeral(const __be32 *saddr, const __be32 *daddr, +u64 secure_ipv4_port_ephemeral(__be32 saddr, __be32 daddr, __be16 dport); +u64 secure_ipv6_port_ephemeral(const __be32 *saddr, const __be32 *daddr, __be16 dport); u32 secure_tcp_seq(__be32 saddr, __be32 daddr, __be16 sport, __be16 dport); --- a/net/core/secure_seq.c +++ b/net/core/secure_seq.c @@ -97,7 +97,7 @@ u32 secure_tcpv6_seq(const __be32 *saddr } EXPORT_SYMBOL(secure_tcpv6_seq); =20 -u32 secure_ipv6_port_ephemeral(const __be32 *saddr, const __be32 *daddr, +u64 secure_ipv6_port_ephemeral(const __be32 *saddr, const __be32 *daddr, __be16 dport) { const struct { @@ -147,7 +147,7 @@ u32 secure_tcp_seq(__be32 saddr, __be32 } EXPORT_SYMBOL_GPL(secure_tcp_seq); =20 -u32 secure_ipv4_port_ephemeral(__be32 saddr, __be32 daddr, __be16 dport) +u64 secure_ipv4_port_ephemeral(__be32 saddr, __be32 daddr, __be16 dport) { net_secret_init(); return siphash_4u32((__force u32)saddr, (__force u32)daddr, --- a/net/ipv4/inet_hashtables.c +++ b/net/ipv4/inet_hashtables.c @@ -464,7 +464,7 @@ not_unique: return -EADDRNOTAVAIL; } =20 -static u32 inet_sk_port_offset(const struct sock *sk) +static u64 inet_sk_port_offset(const struct sock *sk) { const struct inet_sock *inet =3D inet_sk(sk); =20 @@ -683,7 +683,7 @@ EXPORT_SYMBOL_GPL(inet_unhash); static u32 table_perturb[1 << INET_TABLE_PERTURB_SHIFT]; =20 int __inet_hash_connect(struct inet_timewait_death_row *death_row, - struct sock *sk, u32 port_offset, + struct sock *sk, u64 port_offset, int (*check_established)(struct inet_timewait_death_row *, struct sock *, __u16, struct inet_timewait_sock **)) { @@ -726,7 +726,9 @@ int __inet_hash_connect(struct inet_time net_get_random_once(table_perturb, sizeof(table_perturb)); index =3D hash_32(port_offset, INET_TABLE_PERTURB_SHIFT); =20 - offset =3D (READ_ONCE(table_perturb[index]) + port_offset) % remaining; + offset =3D READ_ONCE(table_perturb[index]) + port_offset; + offset %=3D remaining; + /* In first pass we try ports of @low parity. * inet_csk_get_port() does the opposite choice. */ @@ -803,7 +805,7 @@ ok: int inet_hash_connect(struct inet_timewait_death_row *death_row, struct sock *sk) { - u32 port_offset =3D 0; + u64 port_offset =3D 0; =20 if (!inet_sk(sk)->inet_num) port_offset =3D inet_sk_port_offset(sk); --- a/net/ipv6/inet6_hashtables.c +++ b/net/ipv6/inet6_hashtables.c @@ -262,7 +262,7 @@ not_unique: return -EADDRNOTAVAIL; } =20 -static u32 inet6_sk_port_offset(const struct sock *sk) +static u64 inet6_sk_port_offset(const struct sock *sk) { const struct inet_sock *inet =3D inet_sk(sk); =20 @@ -274,7 +274,7 @@ static u32 inet6_sk_port_offset(const st int inet6_hash_connect(struct inet_timewait_death_row *death_row, struct sock *sk) { - u32 port_offset =3D 0; + u64 port_offset =3D 0; =20 if (!inet_sk(sk)->inet_num) port_offset =3D inet6_sk_port_offset(sk); From nobody Tue Apr 28 06:24:51 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id BBB51C433EF for ; Fri, 3 Jun 2022 17:48:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345205AbiFCRse (ORCPT ); Fri, 3 Jun 2022 13:48:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44708 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345186AbiFCRsH (ORCPT ); Fri, 3 Jun 2022 13:48:07 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0069253B5F; Fri, 3 Jun 2022 10:44:42 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id B0951B82435; Fri, 3 Jun 2022 17:44:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EB3B3C385A9; Fri, 3 Jun 2022 17:44:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278280; bh=eWjvNjzueHkRt9//1aAFhyP98DhCROAeyazCCvxs2UA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=M3rAhdjlZib/uceFill+PWvjnm6oNqSCP5TA+JpkG0w9w8XhpcPo3THkp9SKjNECR oTQEdGozk8TXENWDxGFQMh/sRjBN/zW84pwBhWM+nFZfe+bJg+mrm9+90/1vOFswI3 nVJv8Fr146U8jMBK52c6ClIngXR9lxaiiWEJk6wY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Sakari Ailus , Hans Verkuil , Mauro Carvalho Chehab , Mark-PK Tsai Subject: [PATCH 5.4 07/34] media: vim2m: Register video device after setting up internals Date: Fri, 3 Jun 2022 19:43:03 +0200 Message-Id: <20220603173816.210307047@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173815.990072516@linuxfoundation.org> References: <20220603173815.990072516@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Sakari Ailus commit cf7f34777a5b4100a3a44ff95f3d949c62892bdd upstream. Prevent NULL (or close to NULL) pointer dereference in various places by registering the video device only when the V4L2 m2m framework has been set up. Fixes: commit 96d8eab5d0a1 ("V4L/DVB: [v5,2/2] v4l: Add a mem-to-mem videob= uf framework test device") Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Mark-PK Tsai Signed-off-by: Greg Kroah-Hartman Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee --- drivers/media/platform/vim2m.c | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) --- a/drivers/media/platform/vim2m.c +++ b/drivers/media/platform/vim2m.c @@ -1333,12 +1333,6 @@ static int vim2m_probe(struct platform_d vfd->lock =3D &dev->dev_mutex; vfd->v4l2_dev =3D &dev->v4l2_dev; =20 - ret =3D video_register_device(vfd, VFL_TYPE_GRABBER, 0); - if (ret) { - v4l2_err(&dev->v4l2_dev, "Failed to register video device\n"); - goto error_v4l2; - } - video_set_drvdata(vfd, dev); v4l2_info(&dev->v4l2_dev, "Device registered as /dev/video%d\n", vfd->num); @@ -1353,6 +1347,12 @@ static int vim2m_probe(struct platform_d goto error_dev; } =20 + ret =3D video_register_device(vfd, VFL_TYPE_GRABBER, 0); + if (ret) { + v4l2_err(&dev->v4l2_dev, "Failed to register video device\n"); + goto error_m2m; + } + #ifdef CONFIG_MEDIA_CONTROLLER dev->mdev.dev =3D &pdev->dev; strscpy(dev->mdev.model, "vim2m", sizeof(dev->mdev.model)); @@ -1366,7 +1366,7 @@ static int vim2m_probe(struct platform_d MEDIA_ENT_F_PROC_VIDEO_SCALER); if (ret) { v4l2_err(&dev->v4l2_dev, "Failed to init mem2mem media controller\n"); - goto error_dev; + goto error_v4l2; } =20 ret =3D media_device_register(&dev->mdev); @@ -1381,11 +1381,13 @@ static int vim2m_probe(struct platform_d error_m2m_mc: v4l2_m2m_unregister_media_controller(dev->m2m_dev); #endif -error_dev: +error_v4l2: video_unregister_device(&dev->vfd); /* vim2m_device_release called by video_unregister_device to release vari= ous objects */ return ret; -error_v4l2: +error_m2m: + v4l2_m2m_release(dev->m2m_dev); +error_dev: v4l2_device_unregister(&dev->v4l2_dev); error_free: kfree(dev); From nobody Tue Apr 28 06:24:51 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 17DD3CCA473 for ; Fri, 3 Jun 2022 17:53:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345459AbiFCRxf (ORCPT ); Fri, 3 Jun 2022 13:53:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45970 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345602AbiFCRuC (ORCPT ); Fri, 3 Jun 2022 13:50:02 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A925258391; Fri, 3 Jun 2022 10:46:05 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 59D62B8243A; Fri, 3 Jun 2022 17:46:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BFE27C385A9; Fri, 3 Jun 2022 17:46:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278362; bh=JK1DF1VgNAq4TDyPSFj/H5fnS9OR7dFiNc1Idiqfw2Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Qg9HsXlk9LQRb6sViR/Bf/atwLDeo9W9UUYU+FWAlkpVwmyC9JjNlt4GyiP8cU8E6 WcN+QuV3QzESLyfZkmtWLnLE8r9/E442Epcs2wsddEjkeVbFA6EIcvMuF2Hlo1xau1 xg+CmQTWU1Ki0ik7qEGDlXdnl3f+T7U8Uz/5PFWo= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Hans Verkuil , Mauro Carvalho Chehab , Mark-PK Tsai Subject: [PATCH 5.4 08/34] media: vim2m: initialize the media device earlier Date: Fri, 3 Jun 2022 19:43:04 +0200 Message-Id: <20220603173816.239438872@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173815.990072516@linuxfoundation.org> References: <20220603173815.990072516@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Hans Verkuil commit 1a28dce222a6ece725689ad58c0cf4a1b48894f4 upstream. Before the video device node is registered, the v4l2_dev.mdev pointer must be set in order to correctly associate the video device with the media device. Move the initialization of the media device up. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Mark-PK Tsai Signed-off-by: Greg Kroah-Hartman Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee --- drivers/media/platform/vim2m.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) --- a/drivers/media/platform/vim2m.c +++ b/drivers/media/platform/vim2m.c @@ -1347,12 +1347,6 @@ static int vim2m_probe(struct platform_d goto error_dev; } =20 - ret =3D video_register_device(vfd, VFL_TYPE_GRABBER, 0); - if (ret) { - v4l2_err(&dev->v4l2_dev, "Failed to register video device\n"); - goto error_m2m; - } - #ifdef CONFIG_MEDIA_CONTROLLER dev->mdev.dev =3D &pdev->dev; strscpy(dev->mdev.model, "vim2m", sizeof(dev->mdev.model)); @@ -1361,7 +1355,15 @@ static int vim2m_probe(struct platform_d media_device_init(&dev->mdev); dev->mdev.ops =3D &m2m_media_ops; dev->v4l2_dev.mdev =3D &dev->mdev; +#endif =20 + ret =3D video_register_device(vfd, VFL_TYPE_GRABBER, 0); + if (ret) { + v4l2_err(&dev->v4l2_dev, "Failed to register video device\n"); + goto error_m2m; + } + +#ifdef CONFIG_MEDIA_CONTROLLER ret =3D v4l2_m2m_register_media_controller(dev->m2m_dev, vfd, MEDIA_ENT_F_PROC_VIDEO_SCALER); if (ret) { From nobody Tue Apr 28 06:24:51 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5D4A0C43334 for ; Fri, 3 Jun 2022 17:48:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345254AbiFCRsX (ORCPT ); Fri, 3 Jun 2022 13:48:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44936 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345321AbiFCRsI (ORCPT ); Fri, 3 Jun 2022 13:48:08 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1A7735402D; Fri, 3 Jun 2022 10:44:49 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id BB089B82430; Fri, 3 Jun 2022 17:44:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 01735C385A9; Fri, 3 Jun 2022 17:44:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278286; bh=jN3i2LdxfYzhR0w/hB0nyLMKgMI6Tdxlrm4dOLX7fsg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=n/nbTdJ5R5XIvVU33rt9WD8FR8iT+2CzdBB4mIxRYbJj5Qz/zgDPTaZayC0Whi//F CFttcEulqANY6i/yC0qvasaaOOMMW74xEFdTwImt6y8TemMJka0QXaM44r888Qu/Eo EiWkeNKX6Zj08GKVZVSXOoUcNLJtIx2vei63B7JU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Andy Shevchenko , "Rafael J. Wysocki" , dann frazier Subject: [PATCH 5.4 09/34] ACPI: sysfs: Make sparse happy about address space in use Date: Fri, 3 Jun 2022 19:43:05 +0200 Message-Id: <20220603173816.267614104@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173815.990072516@linuxfoundation.org> References: <20220603173815.990072516@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Andy Shevchenko commit bdd56d7d8931e842775d2e5b93d426a8d1940e33 upstream. Sparse is not happy about address space in use in acpi_data_show(): drivers/acpi/sysfs.c:428:14: warning: incorrect type in assignment (differe= nt address spaces) drivers/acpi/sysfs.c:428:14: expected void [noderef] __iomem *base drivers/acpi/sysfs.c:428:14: got void * drivers/acpi/sysfs.c:431:59: warning: incorrect type in argument 4 (differe= nt address spaces) drivers/acpi/sysfs.c:431:59: expected void const *from drivers/acpi/sysfs.c:431:59: got void [noderef] __iomem *base drivers/acpi/sysfs.c:433:30: warning: incorrect type in argument 1 (differe= nt address spaces) drivers/acpi/sysfs.c:433:30: expected void *logical_address drivers/acpi/sysfs.c:433:30: got void [noderef] __iomem *base Indeed, acpi_os_map_memory() returns a void pointer with dropped specific address space. Hence, we don't need to carry out __iomem in acpi_data_show(= ). Signed-off-by: Andy Shevchenko Signed-off-by: Rafael J. Wysocki Cc: dann frazier Signed-off-by: Greg Kroah-Hartman Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee --- drivers/acpi/sysfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/acpi/sysfs.c +++ b/drivers/acpi/sysfs.c @@ -438,7 +438,7 @@ static ssize_t acpi_data_show(struct fil loff_t offset, size_t count) { struct acpi_data_attr *data_attr; - void __iomem *base; + void *base; ssize_t rc; =20 data_attr =3D container_of(bin_attr, struct acpi_data_attr, attr); From nobody Tue Apr 28 06:24:51 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9937CC433EF for ; Fri, 3 Jun 2022 17:49:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345338AbiFCRtn (ORCPT ); Fri, 3 Jun 2022 13:49:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44920 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345381AbiFCRsN (ORCPT ); Fri, 3 Jun 2022 13:48:13 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9B8F6541A6; Fri, 3 Jun 2022 10:45:19 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 3914660A24; Fri, 3 Jun 2022 17:45:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 42503C385A9; Fri, 3 Jun 2022 17:45:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278318; bh=yojwAR4GeocO+V0acQYXPAOcPk/e68dRzRXpL5OJFns=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=l52wWfUEVGH94drrkI8DWznPgt6TGsxu8xfjxLNbOqIjwYUKUTzx5FWfyRoPp3Ity ZdMbsWnOleYotA2N1HxnG+5oReQZ2PhhgxKCMpy1g7thLTdvYajSub0NcaTNtUGUsX wSDALUuVDUS0cSqSra0anW0uuM8s/aevSmZGS3I8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Lorenzo Pieralisi , Veronika Kabatova , Aristeu Rozanski , Ard Biesheuvel , "Rafael J. Wysocki" , dann frazier Subject: [PATCH 5.4 10/34] ACPI: sysfs: Fix BERT error region memory mapping Date: Fri, 3 Jun 2022 19:43:06 +0200 Message-Id: <20220603173816.297006586@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173815.990072516@linuxfoundation.org> References: <20220603173815.990072516@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Lorenzo Pieralisi commit 1bbc21785b7336619fb6a67f1fff5afdaf229acc upstream. Currently the sysfs interface maps the BERT error region as "memory" (through acpi_os_map_memory()) in order to copy the error records into memory buffers through memory operations (eg memory_read_from_buffer()). The OS system cannot detect whether the BERT error region is part of system RAM or it is "device memory" (eg BMC memory) and therefore it cannot detect which memory attributes the bus to memory support (and corresponding kernel mapping, unless firmware provides the required information). The acpi_os_map_memory() arch backend implementation determines the mapping attributes. On arm64, if the BERT error region is not present in the EFI memory map, the error region is mapped as device-nGnRnE; this triggers alignment faults since memcpy unaligned accesses are not allowed in device-nGnRnE regions. The ACPI sysfs code cannot therefore map by default the BERT error region with memory semantics but should use a safer default. Change the sysfs code to map the BERT error region as MMIO (through acpi_os_map_iomem()) and use the memcpy_fromio() interface to read the error region into the kernel buffer. Link: https://lore.kernel.org/linux-arm-kernel/31ffe8fc-f5ee-2858-26c5-0fd8= bdd68702@arm.com Link: https://lore.kernel.org/linux-acpi/CAJZ5v0g+OVbhuUUDrLUCfX_mVqY_e8ubg= LTU98=3DjfjTeb4t+Pw@mail.gmail.com Signed-off-by: Lorenzo Pieralisi Tested-by: Veronika Kabatova Tested-by: Aristeu Rozanski Acked-by: Ard Biesheuvel Signed-off-by: Rafael J. Wysocki Cc: dann frazier Signed-off-by: Greg Kroah-Hartman Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee --- drivers/acpi/sysfs.c | 25 ++++++++++++++++++------- 1 file changed, 18 insertions(+), 7 deletions(-) --- a/drivers/acpi/sysfs.c +++ b/drivers/acpi/sysfs.c @@ -438,19 +438,30 @@ static ssize_t acpi_data_show(struct fil loff_t offset, size_t count) { struct acpi_data_attr *data_attr; - void *base; - ssize_t rc; + void __iomem *base; + ssize_t size; =20 data_attr =3D container_of(bin_attr, struct acpi_data_attr, attr); + size =3D data_attr->attr.size; =20 - base =3D acpi_os_map_memory(data_attr->addr, data_attr->attr.size); + if (offset < 0) + return -EINVAL; + + if (offset >=3D size) + return 0; + + if (count > size - offset) + count =3D size - offset; + + base =3D acpi_os_map_iomem(data_attr->addr, size); if (!base) return -ENOMEM; - rc =3D memory_read_from_buffer(buf, count, &offset, base, - data_attr->attr.size); - acpi_os_unmap_memory(base, data_attr->attr.size); =20 - return rc; + memcpy_fromio(buf, base + offset, count); + + acpi_os_unmap_iomem(base, size); + + return count; } =20 static int acpi_bert_data_init(void *th, struct acpi_data_attr *data_attr) From nobody Tue Apr 28 06:24:51 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 746DDCCA47C for ; Fri, 3 Jun 2022 17:53:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244653AbiFCRx2 (ORCPT ); Fri, 3 Jun 2022 13:53:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45574 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345379AbiFCRsz (ORCPT ); Fri, 3 Jun 2022 13:48:55 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E98155523B; Fri, 3 Jun 2022 10:45:43 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id A6D21B82435; Fri, 3 Jun 2022 17:45:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 197E8C385A9; Fri, 3 Jun 2022 17:45:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278341; bh=+8/rSL0dktqyZfvWABToCYxgk0Wct5z+yxpZFfy6gak=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=nIIxnuG0XPIsjGoqLbBJnOPu0z/HducjIYpHWMU2nn0KVJ67MDdnll/fbAAEEWUi3 3t15U0+GR2yfBWZEjcmUVjguvrozc9yp3xCzVxi5kHSTA2Awrs/Fc/CvPDkh7NEauO XpcBs6S5YtRfleAuHsKzjralnRhoWO2MwQDJ7uV8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, IotaHydrae , Andre Przywara , Linus Walleij , Sasha Levin Subject: [PATCH 5.4 11/34] pinctrl: sunxi: fix f1c100s uart2 function Date: Fri, 3 Jun 2022 19:43:07 +0200 Message-Id: <20220603173816.325039941@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173815.990072516@linuxfoundation.org> References: <20220603173815.990072516@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: IotaHydrae [ Upstream commit fa8785e5931367e2b43f2c507f26bcf3e281c0ca ] Change suniv f1c100s pinctrl,PD14 multiplexing function lvds1 to uart2 When the pin PD13 and PD14 is setting up to uart2 function in dts, there's an error occurred: 1c20800.pinctrl: unsupported function uart2 on pin PD14 Because 'uart2' is not any one multiplexing option of PD14, and pinctrl don't know how to configure it. So change the pin PD14 lvds1 function to uart2. Signed-off-by: IotaHydrae Reviewed-by: Andre Przywara Link: https://lore.kernel.org/r/tencent_70C1308DDA794C81CAEF389049055BACEC0= 9@qq.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee --- drivers/pinctrl/sunxi/pinctrl-suniv-f1c100s.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pinctrl/sunxi/pinctrl-suniv-f1c100s.c b/drivers/pinctr= l/sunxi/pinctrl-suniv-f1c100s.c index 2801ca706273..68a5b627fb9b 100644 --- a/drivers/pinctrl/sunxi/pinctrl-suniv-f1c100s.c +++ b/drivers/pinctrl/sunxi/pinctrl-suniv-f1c100s.c @@ -204,7 +204,7 @@ static const struct sunxi_desc_pin suniv_f1c100s_pins[]= =3D { SUNXI_FUNCTION(0x0, "gpio_in"), SUNXI_FUNCTION(0x1, "gpio_out"), SUNXI_FUNCTION(0x2, "lcd"), /* D20 */ - SUNXI_FUNCTION(0x3, "lvds1"), /* RX */ + SUNXI_FUNCTION(0x3, "uart2"), /* RX */ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 14)), SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 15), SUNXI_FUNCTION(0x0, "gpio_in"), --=20 2.35.1 From nobody Tue Apr 28 06:24:51 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3A24FC433EF for ; Fri, 3 Jun 2022 17:59:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346036AbiFCR7C (ORCPT ); Fri, 3 Jun 2022 13:59:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46024 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344991AbiFCRs4 (ORCPT ); Fri, 3 Jun 2022 13:48:56 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5076855359; Fri, 3 Jun 2022 10:45:45 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id B52A260C47; Fri, 3 Jun 2022 17:45:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C6F31C385B8; Fri, 3 Jun 2022 17:45:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278344; bh=MFTKNe6w2Me8NT2WM3LGHJPXBnG8b7aPudi9BrSnwjE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=dOmZjO8aPE0znGPYM0Q2rtcySQnxnW/bYxYjEpzWmZsLMhk3QqXmNHpj0wP4LZ2fB wgzjeWiCJnHcleEcUQLxhxHxQfisByeTatY9IpvNEyeissxv/X2sIUvnKcfx2wrkgc n66ywdmLk8/Vs+gPjNTeJYRZeh0C5gfxw1P/3kOw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Thomas Bartschies , Steffen Klassert , Sasha Levin Subject: [PATCH 5.4 12/34] net: af_key: check encryption module availability consistency Date: Fri, 3 Jun 2022 19:43:08 +0200 Message-Id: <20220603173816.353260373@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173815.990072516@linuxfoundation.org> References: <20220603173815.990072516@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Thomas Bartschies [ Upstream commit 015c44d7bff3f44d569716117becd570c179ca32 ] Since the recent introduction supporting the SM3 and SM4 hash algos for IPs= ec, the kernel produces invalid pfkey acquire messages, when these encryption modules are = disabled. This happens because the availability of the algos wasn't checked in all necessa= ry functions. This patch adds these checks. Signed-off-by: Thomas Bartschies Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee --- net/key/af_key.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/net/key/af_key.c b/net/key/af_key.c index f67d3ba72c49..dd064d5eff6e 100644 --- a/net/key/af_key.c +++ b/net/key/af_key.c @@ -2904,7 +2904,7 @@ static int count_ah_combs(const struct xfrm_tmpl *t) break; if (!aalg->pfkey_supported) continue; - if (aalg_tmpl_set(t, aalg)) + if (aalg_tmpl_set(t, aalg) && aalg->available) sz +=3D sizeof(struct sadb_comb); } return sz + sizeof(struct sadb_prop); @@ -2922,7 +2922,7 @@ static int count_esp_combs(const struct xfrm_tmpl *t) if (!ealg->pfkey_supported) continue; =20 - if (!(ealg_tmpl_set(t, ealg))) + if (!(ealg_tmpl_set(t, ealg) && ealg->available)) continue; =20 for (k =3D 1; ; k++) { @@ -2933,7 +2933,7 @@ static int count_esp_combs(const struct xfrm_tmpl *t) if (!aalg->pfkey_supported) continue; =20 - if (aalg_tmpl_set(t, aalg)) + if (aalg_tmpl_set(t, aalg) && aalg->available) sz +=3D sizeof(struct sadb_comb); } } --=20 2.35.1 From nobody Tue Apr 28 06:24:51 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5C7F4C43334 for ; Fri, 3 Jun 2022 17:59:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345936AbiFCR7G (ORCPT ); Fri, 3 Jun 2022 13:59:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46538 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345322AbiFCRtU (ORCPT ); Fri, 3 Jun 2022 13:49:20 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5A9205536F; Fri, 3 Jun 2022 10:45:48 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id A598460C4E; Fri, 3 Jun 2022 17:45:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AC186C3411E; Fri, 3 Jun 2022 17:45:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278347; bh=yq3kpL5uLmlVYSLy8oKazIs+8ak4Uz688yskPdhZX6I=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=sv0tQEovZmz+rTRhPMtAliTWRX6c8R92DPzdqLQ0VYyAY9s2FaIx/8L7RBEFci72a ZZ2gxLE1EczxHocd5yfq9eOalsRwITGRE7UCDkUOsD0ftPLJqyD/TG5GI8Ndw+5Zmu szb4Zhifi4IdX/watS6Hq8d3kqSe4kbQ1V9Zv8IE= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, David Wilder , Dylan Hung , Joel Stanley , "David S. Miller" , Sasha Levin Subject: [PATCH 5.4 13/34] net: ftgmac100: Disable hardware checksum on AST2600 Date: Fri, 3 Jun 2022 19:43:09 +0200 Message-Id: <20220603173816.381964580@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173815.990072516@linuxfoundation.org> References: <20220603173815.990072516@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Joel Stanley [ Upstream commit 6fd45e79e8b93b8d22fb8fe22c32fbad7e9190bd ] The AST2600 when using the i210 NIC over NC-SI has been observed to produce incorrect checksum results with specific MTU values. This was first observed when sending data across a long distance set of networks. On a local network, the following test was performed using a 1MB file of random data. On the receiver run this script: #!/bin/bash while [ 1 ]; do # Zero the stats nstat -r > /dev/null nc -l 9899 > test-file # Check for checksum errors TcpInCsumErrors=3D$(nstat | grep TcpInCsumErrors) if [ -z "$TcpInCsumErrors" ]; then echo No TcpInCsumErrors else echo TcpInCsumErrors =3D $TcpInCsumErrors fi done On an AST2600 system: # nc 9899 < test-file The test was repeated with various MTU values: # ip link set mtu 1410 dev eth0 The observed results: 1500 - good 1434 - bad 1400 - good 1410 - bad 1420 - good The test was repeated after disabling tx checksumming: # ethtool -K eth0 tx-checksumming off And all MTU values tested resulted in transfers without error. An issue with the driver cannot be ruled out, however there has been no bug discovered so far. David has done the work to take the original bug report of slow data transfer between long distance connections and triaged it down to this test case. The vendor suspects this this is a hardware issue when using NC-SI. The fixes line refers to the patch that introduced AST2600 support. Reported-by: David Wilder Reviewed-by: Dylan Hung Signed-off-by: Joel Stanley Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee --- drivers/net/ethernet/faraday/ftgmac100.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/net/ethernet/faraday/ftgmac100.c b/drivers/net/etherne= t/faraday/ftgmac100.c index 2c06cdcd3e75..d7478d332820 100644 --- a/drivers/net/ethernet/faraday/ftgmac100.c +++ b/drivers/net/ethernet/faraday/ftgmac100.c @@ -1880,6 +1880,11 @@ static int ftgmac100_probe(struct platform_device *p= dev) /* AST2400 doesn't have working HW checksum generation */ if (np && (of_device_is_compatible(np, "aspeed,ast2400-mac"))) netdev->hw_features &=3D ~NETIF_F_HW_CSUM; + + /* AST2600 tx checksum with NCSI is broken */ + if (priv->use_ncsi && of_device_is_compatible(np, "aspeed,ast2600-mac")) + netdev->hw_features &=3D ~NETIF_F_HW_CSUM; + if (np && of_get_property(np, "no-hw-checksum", NULL)) netdev->hw_features &=3D ~(NETIF_F_HW_CSUM | NETIF_F_RXCSUM); netdev->features |=3D netdev->hw_features; --=20 2.35.1 From nobody Tue Apr 28 06:24:51 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id AD803CCA480 for ; Fri, 3 Jun 2022 17:53:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345362AbiFCRxX (ORCPT ); Fri, 3 Jun 2022 13:53:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44936 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345474AbiFCRtu (ORCPT ); Fri, 3 Jun 2022 13:49:50 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B9A9356216; Fri, 3 Jun 2022 10:45:51 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 8A20260C47; Fri, 3 Jun 2022 17:45:50 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 885ECC385A9; Fri, 3 Jun 2022 17:45:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278350; bh=BzfC/E5W1JA+c9kXAqd5dIf01JrtHZXYXprhMh+nHuI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=jiD1skAjr+myAkKXLuzuQahvGoWqqiq3Frmt8aQ69c7rXvAjkKp0PRfrpw4xrssaz TH0Fmr5VXUW+9ZY3ieG3ZQVuVAJLkGMIMeMFObZt/7Nfn8QJ2DLRzaZ077mAsxW/PI Pp4nj5vL3tmnAz9AzUuAvXaWg2mrnMVkqKKEDPQs= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Mika Westerberg , "From: Andy Shevchenko" , Wolfram Sang , Sasha Levin Subject: [PATCH 5.4 14/34] i2c: ismt: Provide a DMA buffer for Interrupt Cause Logging Date: Fri, 3 Jun 2022 19:43:10 +0200 Message-Id: <20220603173816.410177422@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173815.990072516@linuxfoundation.org> References: <20220603173815.990072516@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Mika Westerberg [ Upstream commit 17a0f3acdc6ec8b89ad40f6e22165a4beee25663 ] Before sending a MSI the hardware writes information pertinent to the interrupt cause to a memory location pointed by SMTICL register. This memory holds three double words where the least significant bit tells whether the interrupt cause of master/target/error is valid. The driver does not use this but we need to set it up because otherwise it will perform DMA write to the default address (0) and this will cause an IOMMU fault such as below: DMAR: DRHD: handling fault status reg 2 DMAR: [DMA Write] Request device [00:12.0] PASID ffffffff fault addr 0 [fault reason 05] PTE Write access is not set To prevent this from happening, provide a proper DMA buffer for this that then gets mapped by the IOMMU accordingly. Signed-off-by: Mika Westerberg Reviewed-by: From: Andy Shevchenko Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee --- drivers/i2c/busses/i2c-ismt.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/drivers/i2c/busses/i2c-ismt.c b/drivers/i2c/busses/i2c-ismt.c index 2f95e25a10f7..53325419ec13 100644 --- a/drivers/i2c/busses/i2c-ismt.c +++ b/drivers/i2c/busses/i2c-ismt.c @@ -81,6 +81,7 @@ =20 #define ISMT_DESC_ENTRIES 2 /* number of descriptor entries */ #define ISMT_MAX_RETRIES 3 /* number of SMBus retries to attempt */ +#define ISMT_LOG_ENTRIES 3 /* number of interrupt cause log entries */ =20 /* Hardware Descriptor Constants - Control Field */ #define ISMT_DESC_CWRL 0x01 /* Command/Write Length */ @@ -174,6 +175,8 @@ struct ismt_priv { u8 head; /* ring buffer head pointer */ struct completion cmp; /* interrupt completion */ u8 buffer[I2C_SMBUS_BLOCK_MAX + 16]; /* temp R/W data buffer */ + dma_addr_t log_dma; + u32 *log; }; =20 /** @@ -408,6 +411,9 @@ static int ismt_access(struct i2c_adapter *adap, u16 ad= dr, memset(desc, 0, sizeof(struct ismt_desc)); desc->tgtaddr_rw =3D ISMT_DESC_ADDR_RW(addr, read_write); =20 + /* Always clear the log entries */ + memset(priv->log, 0, ISMT_LOG_ENTRIES * sizeof(u32)); + /* Initialize common control bits */ if (likely(pci_dev_msi_enabled(priv->pci_dev))) desc->control =3D ISMT_DESC_INT | ISMT_DESC_FAIR; @@ -697,6 +703,8 @@ static void ismt_hw_init(struct ismt_priv *priv) /* initialize the Master Descriptor Base Address (MDBA) */ writeq(priv->io_rng_dma, priv->smba + ISMT_MSTR_MDBA); =20 + writeq(priv->log_dma, priv->smba + ISMT_GR_SMTICL); + /* initialize the Master Control Register (MCTRL) */ writel(ISMT_MCTRL_MEIE, priv->smba + ISMT_MSTR_MCTRL); =20 @@ -784,6 +792,12 @@ static int ismt_dev_init(struct ismt_priv *priv) priv->head =3D 0; init_completion(&priv->cmp); =20 + priv->log =3D dmam_alloc_coherent(&priv->pci_dev->dev, + ISMT_LOG_ENTRIES * sizeof(u32), + &priv->log_dma, GFP_KERNEL); + if (!priv->log) + return -ENOMEM; + return 0; } =20 --=20 2.35.1 From nobody Tue Apr 28 06:24:51 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7A3E3C433EF for ; Fri, 3 Jun 2022 17:53:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345502AbiFCRxD (ORCPT ); Fri, 3 Jun 2022 13:53:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45970 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345491AbiFCRt4 (ORCPT ); Fri, 3 Jun 2022 13:49:56 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E100556231; Fri, 3 Jun 2022 10:45:55 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 21982B82435; Fri, 3 Jun 2022 17:45:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 806BFC385A9; Fri, 3 Jun 2022 17:45:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278352; bh=1+z+sNbxT56SjlBQgUUIv3b78tcRXKNXzlTy+NZVN0c=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GSV6gubVnWOOQYvAFReBayAyAferHq9fbMEZI+bXN49pQqk6o8IpMf8nJEjoKPax7 wxIcpBtvMcRlIN7W+DWIcWmRle2oPtgJEp7epUd64K7keoMBZnSDTxwCszrXWouaLe B2Qsr6qqFB64Ml3VqT14liVg9WDmCAmM/JB+UkGw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Szymon Balcerak , Piyush Malgujar , Wolfram Sang , Sasha Levin Subject: [PATCH 5.4 15/34] drivers: i2c: thunderx: Allow driver to work with ACPI defined TWSI controllers Date: Fri, 3 Jun 2022 19:43:11 +0200 Message-Id: <20220603173816.439251988@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173815.990072516@linuxfoundation.org> References: <20220603173815.990072516@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Piyush Malgujar [ Upstream commit 03a35bc856ddc09f2cc1f4701adecfbf3b464cb3 ] Due to i2c->adap.dev.fwnode not being set, ACPI_COMPANION() wasn't properly found for TWSI controllers. Signed-off-by: Szymon Balcerak Signed-off-by: Piyush Malgujar Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee --- drivers/i2c/busses/i2c-thunderx-pcidrv.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/i2c/busses/i2c-thunderx-pcidrv.c b/drivers/i2c/busses/= i2c-thunderx-pcidrv.c index 19f8eec38717..107aeb8b54da 100644 --- a/drivers/i2c/busses/i2c-thunderx-pcidrv.c +++ b/drivers/i2c/busses/i2c-thunderx-pcidrv.c @@ -208,6 +208,7 @@ static int thunder_i2c_probe_pci(struct pci_dev *pdev, i2c->adap.bus_recovery_info =3D &octeon_i2c_recovery_info; i2c->adap.dev.parent =3D dev; i2c->adap.dev.of_node =3D pdev->dev.of_node; + i2c->adap.dev.fwnode =3D dev->fwnode; snprintf(i2c->adap.name, sizeof(i2c->adap.name), "Cavium ThunderX i2c adapter at %s", dev_name(dev)); i2c_set_adapdata(&i2c->adap, i2c); --=20 2.35.1 From nobody Tue Apr 28 06:24:51 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 25D14CCA473 for ; Fri, 3 Jun 2022 17:53:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345556AbiFCRxJ (ORCPT ); Fri, 3 Jun 2022 13:53:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43606 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345515AbiFCRt5 (ORCPT ); Fri, 3 Jun 2022 13:49:57 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 18C3D57B32; Fri, 3 Jun 2022 10:45:57 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 9399E60C52; Fri, 3 Jun 2022 17:45:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6A853C385A9; Fri, 3 Jun 2022 17:45:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278356; bh=ZCDvb/lEcXJjYOpYuWAGBXcbz47R0k27Spe8HvZyXr4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=mx8/v7R5X8mZvan7Fs84DM37yXuX2XtZbgW40Jlp3XxovwW7QJeiD9a9G4Dn/QfwM ituBrhymYCvIf5fKpowm8XPmEpDW8KbVSxwjlgOL6/CmJpwfRW5mWBHSFY4sUfmMK7 Ww9wmJvqrtzyihhyduimH+9dRwKABkcXBUmdsnUs= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Stephen Brennan , David Howells , Andrew Morton , keyrings@vger.kernel.org, Jarkko Sakkinen , Linus Torvalds Subject: [PATCH 5.4 16/34] assoc_array: Fix BUG_ON during garbage collect Date: Fri, 3 Jun 2022 19:43:12 +0200 Message-Id: <20220603173816.467643538@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173815.990072516@linuxfoundation.org> References: <20220603173815.990072516@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Stephen Brennan commit d1dc87763f406d4e67caf16dbe438a5647692395 upstream. A rare BUG_ON triggered in assoc_array_gc: [3430308.818153] kernel BUG at lib/assoc_array.c:1609! Which corresponded to the statement currently at line 1593 upstream: BUG_ON(assoc_array_ptr_is_meta(p)); Using the data from the core dump, I was able to generate a userspace reproducer[1] and determine the cause of the bug. [1]: https://github.com/brenns10/kernel_stuff/tree/master/assoc_array_gc After running the iterator on the entire branch, an internal tree node looked like the following: NODE (nr_leaves_on_branch: 3) SLOT [0] NODE (2 leaves) SLOT [1] NODE (1 leaf) SLOT [2..f] NODE (empty) In the userspace reproducer, the pr_devel output when compressing this node was: -- compress node 0x5607cc089380 -- free=3D0, leaves=3D0 [0] retain node 2/1 [nx 0] [1] fold node 1/1 [nx 0] [2] fold node 0/1 [nx 2] [3] fold node 0/2 [nx 2] [4] fold node 0/3 [nx 2] [5] fold node 0/4 [nx 2] [6] fold node 0/5 [nx 2] [7] fold node 0/6 [nx 2] [8] fold node 0/7 [nx 2] [9] fold node 0/8 [nx 2] [10] fold node 0/9 [nx 2] [11] fold node 0/10 [nx 2] [12] fold node 0/11 [nx 2] [13] fold node 0/12 [nx 2] [14] fold node 0/13 [nx 2] [15] fold node 0/14 [nx 2] after: 3 At slot 0, an internal node with 2 leaves could not be folded into the node, because there was only one available slot (slot 0). Thus, the internal node was retained. At slot 1, the node had one leaf, and was able to be folded in successfully. The remaining nodes had no leaves, and so were removed. By the end of the compression stage, there were 14 free slots, and only 3 leaf nodes. The tree was ascended and then its parent node was compressed. When this node was seen, it could not be folded, due to the internal node it contained. The invariant for compression in this function is: whenever nr_leaves_on_branch < ASSOC_ARRAY_FAN_OUT, the node should contain all leaf nodes. The compression step currently cannot guarantee this, given the corner case shown above. To fix this issue, retry compression whenever we have retained a node, and yet nr_leaves_on_branch < ASSOC_ARRAY_FAN_OUT. This second compression will then allow the node in slot 1 to be folded in, satisfying the invariant. Below is the output of the reproducer once the fix is applied: -- compress node 0x560e9c562380 -- free=3D0, leaves=3D0 [0] retain node 2/1 [nx 0] [1] fold node 1/1 [nx 0] [2] fold node 0/1 [nx 2] [3] fold node 0/2 [nx 2] [4] fold node 0/3 [nx 2] [5] fold node 0/4 [nx 2] [6] fold node 0/5 [nx 2] [7] fold node 0/6 [nx 2] [8] fold node 0/7 [nx 2] [9] fold node 0/8 [nx 2] [10] fold node 0/9 [nx 2] [11] fold node 0/10 [nx 2] [12] fold node 0/11 [nx 2] [13] fold node 0/12 [nx 2] [14] fold node 0/13 [nx 2] [15] fold node 0/14 [nx 2] internal nodes remain despite enough space, retrying -- compress node 0x560e9c562380 -- free=3D14, leaves=3D1 [0] fold node 2/15 [nx 0] after: 3 Changes =3D=3D=3D=3D=3D=3D=3D DH: - Use false instead of 0. - Reorder the inserted lines in a couple of places to put retained before next_slot. ver #2) - Fix typo in pr_devel, correct comparison to "<=3D" Fixes: 3cb989501c26 ("Add a generic associative array implementation.") Cc: Signed-off-by: Stephen Brennan Signed-off-by: David Howells cc: Andrew Morton cc: keyrings@vger.kernel.org Link: https://lore.kernel.org/r/20220511225517.407935-1-stephen.s.brennan@o= racle.com/ # v1 Link: https://lore.kernel.org/r/20220512215045.489140-1-stephen.s.brennan@o= racle.com/ # v2 Reviewed-by: Jarkko Sakkinen Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee --- lib/assoc_array.c | 8 ++++++++ 1 file changed, 8 insertions(+) --- a/lib/assoc_array.c +++ b/lib/assoc_array.c @@ -1462,6 +1462,7 @@ int assoc_array_gc(struct assoc_array *a struct assoc_array_ptr *cursor, *ptr; struct assoc_array_ptr *new_root, *new_parent, **new_ptr_pp; unsigned long nr_leaves_on_tree; + bool retained; int keylen, slot, nr_free, next_slot, i; =20 pr_devel("-->%s()\n", __func__); @@ -1538,6 +1539,7 @@ continue_node: goto descend; } =20 +retry_compress: pr_devel("-- compress node %p --\n", new_n); =20 /* Count up the number of empty slots in this node and work out the @@ -1555,6 +1557,7 @@ continue_node: pr_devel("free=3D%d, leaves=3D%lu\n", nr_free, new_n->nr_leaves_on_branch= ); =20 /* See what we can fold in */ + retained =3D false; next_slot =3D 0; for (slot =3D 0; slot < ASSOC_ARRAY_FAN_OUT; slot++) { struct assoc_array_shortcut *s; @@ -1604,9 +1607,14 @@ continue_node: pr_devel("[%d] retain node %lu/%d [nx %d]\n", slot, child->nr_leaves_on_branch, nr_free + 1, next_slot); + retained =3D true; } } =20 + if (retained && new_n->nr_leaves_on_branch <=3D ASSOC_ARRAY_FAN_OUT) { + pr_devel("internal nodes remain despite enough space, retrying\n"); + goto retry_compress; + } pr_devel("after: %lu\n", new_n->nr_leaves_on_branch); =20 nr_leaves_on_tree =3D new_n->nr_leaves_on_branch; From nobody Tue Apr 28 06:24:51 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 59FDCCCA47C for ; Fri, 3 Jun 2022 17:53:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345572AbiFCRxP (ORCPT ); Fri, 3 Jun 2022 13:53:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44394 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345536AbiFCRt6 (ORCPT ); Fri, 3 Jun 2022 13:49:58 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 37FEE580CF; Fri, 3 Jun 2022 10:46:00 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id BA66F60A57; Fri, 3 Jun 2022 17:45:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CA453C3411C; Fri, 3 Jun 2022 17:45:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278359; bh=zfTUqo6GDEzMCKgCIFEddCEZjBTmFlj6lKUkd3eMTDw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=cBX5oLD0325wlVWpKvDwVO+CWNF+eO5AxiZy15Ig42oKg9SrfIVJjTyuZ3aDBmqQO E1UcNmEyLQu0DMHWxK+eww1cRnZNdLtvEn5+bjZOWgVEO+jDzmLr7UL7QXrgIxmnnW ESKp3Ae0/bF2dx3DpLuOu16GhWKsWp5bcEnj3coY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Miri Korenblit , Luca Coelho , Johannes Berg Subject: [PATCH 5.4 17/34] cfg80211: set custom regdomain after wiphy registration Date: Fri, 3 Jun 2022 19:43:13 +0200 Message-Id: <20220603173816.495522053@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173815.990072516@linuxfoundation.org> References: <20220603173815.990072516@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Miri Korenblit commit 1b7b3ac8ff3317cdcf07a1c413de9bdb68019c2b upstream. We used to set regulatory info before the registration of the device and then the regulatory info didn't get set, because the device isn't registered so there isn't a device to set the regulatory info for. So set the regulatory info after the device registration. Call reg_process_self_managed_hints() once again after the device registration because it does nothing before it. Signed-off-by: Miri Korenblit Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210618133832.c96eadcffe80.I86799c= 2c866b5610b4cf91115c21d8ceb525c5aa@changeid Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee --- net/wireless/core.c | 8 ++++---- net/wireless/reg.c | 1 + 2 files changed, 5 insertions(+), 4 deletions(-) --- a/net/wireless/core.c +++ b/net/wireless/core.c @@ -5,7 +5,7 @@ * Copyright 2006-2010 Johannes Berg * Copyright 2013-2014 Intel Mobile Communications GmbH * Copyright 2015-2017 Intel Deutschland GmbH - * Copyright (C) 2018-2019 Intel Corporation + * Copyright (C) 2018-2021 Intel Corporation */ =20 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt @@ -891,9 +891,6 @@ int wiphy_register(struct wiphy *wiphy) return res; } =20 - /* set up regulatory info */ - wiphy_regulatory_register(wiphy); - list_add_rcu(&rdev->list, &cfg80211_rdev_list); cfg80211_rdev_list_generation++; =20 @@ -904,6 +901,9 @@ int wiphy_register(struct wiphy *wiphy) cfg80211_debugfs_rdev_add(rdev); nl80211_notify_wiphy(rdev, NL80211_CMD_NEW_WIPHY); =20 + /* set up regulatory info */ + wiphy_regulatory_register(wiphy); + if (wiphy->regulatory_flags & REGULATORY_CUSTOM_REG) { struct regulatory_request request; =20 --- a/net/wireless/reg.c +++ b/net/wireless/reg.c @@ -3790,6 +3790,7 @@ void wiphy_regulatory_register(struct wi =20 wiphy_update_regulatory(wiphy, lr->initiator); wiphy_all_share_dfs_chan_state(wiphy); + reg_process_self_managed_hints(); } =20 void wiphy_regulatory_deregister(struct wiphy *wiphy) From nobody Tue Apr 28 06:24:51 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9AAC7C433EF for ; Fri, 3 Jun 2022 17:48:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244916AbiFCRsk (ORCPT ); Fri, 3 Jun 2022 13:48:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44962 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345237AbiFCRsJ (ORCPT ); Fri, 3 Jun 2022 13:48:09 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D3CBE54029; Fri, 3 Jun 2022 10:44:52 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 2DA4761B38; Fri, 3 Jun 2022 17:44:50 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 29A56C385A9; Fri, 3 Jun 2022 17:44:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278289; bh=X+TGgT1zSmpB0nRebXLItJ/4nmBeSj1ttQzmYio8cEc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Yk8WJN2fgDlkBhBiEmAw73EbPhWdG47WlnhwHqxesb7HizFUjlTWwLEZwByWzmbbb c6sKnpStkRf9P07BwOmhR+/4lNcbIc+ehEfBsvKfnCjEIi19j/FSw62YXFVYqQWkp5 zKCnK4SeOQkeHGy4ZPh+pMRqOgOfeNrJ1Elor0d0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, "Gustavo A. R. Silva" Subject: [PATCH 5.4 18/34] drm/i915: Fix -Wstringop-overflow warning in call to intel_read_wm_latency() Date: Fri, 3 Jun 2022 19:43:14 +0200 Message-Id: <20220603173816.524059323@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173815.990072516@linuxfoundation.org> References: <20220603173815.990072516@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Gustavo A. R. Silva commit 336feb502a715909a8136eb6a62a83d7268a353b upstream. Fix the following -Wstringop-overflow warnings when building with GCC-11: drivers/gpu/drm/i915/intel_pm.c:3106:9: warning: =E2=80=98intel_read_wm_lat= ency=E2=80=99 accessing 16 bytes in a region of size 10 [-Wstringop-overflo= w=3D] 3106 | intel_read_wm_latency(dev_priv, dev_priv->wm.pri_latency); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/i915/intel_pm.c:3106:9: note: referencing argument 2 of typ= e =E2=80=98u16 *=E2=80=99 {aka =E2=80=98short unsigned int *=E2=80=99} drivers/gpu/drm/i915/intel_pm.c:2861:13: note: in a call to function =E2=80= =98intel_read_wm_latency=E2=80=99 2861 | static void intel_read_wm_latency(struct drm_i915_private *dev_priv, | ^~~~~~~~~~~~~~~~~~~~~ by removing the over-specified array size from the argument declarations. It seems that this code is actually safe because the size of the array depends on the hardware generation, and the function checks for that. Notice that wm can be an array of 5 elements: drivers/gpu/drm/i915/intel_pm.c:3109: intel_read_wm_latency(dev_priv, dev= _priv->wm.pri_latency); or an array of 8 elements: drivers/gpu/drm/i915/intel_pm.c:3131: intel_read_wm_latency(dev_priv, dev= _priv->wm.skl_latency); and the compiler legitimately complains about that. This helps with the ongoing efforts to globally enable -Wstringop-overflow. Link: https://github.com/KSPP/linux/issues/181 Signed-off-by: Gustavo A. R. Silva Signed-off-by: Greg Kroah-Hartman Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee --- drivers/gpu/drm/i915/intel_pm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -2822,7 +2822,7 @@ hsw_compute_linetime_wm(const struct int } =20 static void intel_read_wm_latency(struct drm_i915_private *dev_priv, - u16 wm[8]) + u16 wm[]) { struct intel_uncore *uncore =3D &dev_priv->uncore; =20 From nobody Tue Apr 28 06:24:51 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E0739CCA47C for ; Fri, 3 Jun 2022 17:49:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345055AbiFCRtB (ORCPT ); Fri, 3 Jun 2022 13:49:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46472 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345260AbiFCRsK (ORCPT ); Fri, 3 Jun 2022 13:48:10 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3C81C5520E; Fri, 3 Jun 2022 10:44:55 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id B97B4B82433; Fri, 3 Jun 2022 17:44:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E76C7C3411D; Fri, 3 Jun 2022 17:44:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278292; bh=h9It75E2GU6uXoKgZsSgzWHIBhp5btN2jq+oo9/WLRg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=WJbzD5myBGJ5d//c+GdzR/EkQWTYCnOxAcyLFk77pmsTNDVl4dfewLVGQNI+MQT2w gXWgHu8HjljvAP+EPgQAgcMItT1we6tbk6mzcV+IVb/O2ox4DgSuOtajDqX2ZpkAuZ wvGMXVIlRPU9UypNQRXqov/c8lOyeiRxK55+oJmo= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Ariadne Conill , Michael Kerrisk , Matthew Wilcox , Christian Brauner , Rich Felker , Eric Biederman , Alexander Viro , linux-fsdevel@vger.kernel.org, Kees Cook , Andy Lutomirski , Vegard Nossum Subject: [PATCH 5.4 19/34] exec: Force single empty string when argv is empty Date: Fri, 3 Jun 2022 19:43:15 +0200 Message-Id: <20220603173816.551421192@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173815.990072516@linuxfoundation.org> References: <20220603173815.990072516@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Kees Cook commit dcd46d897adb70d63e025f175a00a89797d31a43 upstream. Quoting[1] Ariadne Conill: "In several other operating systems, it is a hard requirement that the second argument to execve(2) be the name of a program, thus prohibiting a scenario where argc < 1. POSIX 2017 also recommends this behaviour, but it is not an explicit requirement[2]: The argument arg0 should point to a filename string that is associated with the process being started by one of the exec functions. ... Interestingly, Michael Kerrisk opened an issue about this in 2008[3], but there was no consensus to support fixing this issue then. Hopefully now that CVE-2021-4034 shows practical exploitative use[4] of this bug in a shellcode, we can reconsider. This issue is being tracked in the KSPP issue tracker[5]." While the initial code searches[6][7] turned up what appeared to be mostly corner case tests, trying to that just reject argv =3D=3D NULL (or an immediately terminated pointer list) quickly started tripping[8] existing userspace programs. The next best approach is forcing a single empty string into argv and adjusting argc to match. The number of programs depending on argc =3D=3D 0 seems a smaller set than those calling execve with a NULL argv. Account for the additional stack space in bprm_stack_limits(). Inject an empty string when argc =3D=3D 0 (and set argc =3D 1). Warn about the case so userspace has some notice about the change: process './argc0' launched './argc0' with NULL argv: empty string added Additionally WARN() and reject NULL argv usage for kernel threads. [1] https://lore.kernel.org/lkml/20220127000724.15106-1-ariadne@dereference= d.org/ [2] https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html [3] https://bugzilla.kernel.org/show_bug.cgi?id=3D8408 [4] https://www.qualys.com/2022/01/25/cve-2021-4034/pwnkit.txt [5] https://github.com/KSPP/linux/issues/176 [6] https://codesearch.debian.net/search?q=3Dexecve%5C+*%5C%28%5B%5E%2C%5D%= 2B%2C+*NULL&literal=3D0 [7] https://codesearch.debian.net/search?q=3Dexeclp%3F%5Cs*%5C%28%5B%5E%2C%= 5D%2B%2C%5Cs*NULL&literal=3D0 [8] https://lore.kernel.org/lkml/20220131144352.GE16385@xsang-OptiPlex-9020/ Reported-by: Ariadne Conill Reported-by: Michael Kerrisk Cc: Matthew Wilcox Cc: Christian Brauner Cc: Rich Felker Cc: Eric Biederman Cc: Alexander Viro Cc: linux-fsdevel@vger.kernel.org Cc: stable@vger.kernel.org Signed-off-by: Kees Cook Acked-by: Christian Brauner Acked-by: Ariadne Conill Acked-by: Andy Lutomirski Link: https://lore.kernel.org/r/20220201000947.2453721-1-keescook@chromium.= org [vegard: fixed conflicts due to missing 886d7de631da71e30909980fdbf318f7caade262^- and 3950e975431bc914f7e81b8f2a2dbdf2064acb0f^-] Signed-off-by: Vegard Nossum Signed-off-by: Greg Kroah-Hartman Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee --- fs/exec.c | 25 ++++++++++++++++++++++++- 1 file changed, 24 insertions(+), 1 deletion(-) This has been tested in both argc =3D=3D 0 and argc >=3D 1 cases, but I wou= ld still appreciate a review given the differences with mainline. If it's considered too risky I'm also fine with dropping it -- just wanted to make sure this didn't fall through the cracks, as it does block a real (albeit old by now) exploit. --- a/fs/exec.c +++ b/fs/exec.c @@ -454,6 +454,9 @@ static int prepare_arg_pages(struct linu unsigned long limit, ptr_size; =20 bprm->argc =3D count(argv, MAX_ARG_STRINGS); + if (bprm->argc =3D=3D 0) + pr_warn_once("process '%s' launched '%s' with NULL argv: empty string ad= ded\n", + current->comm, bprm->filename); if (bprm->argc < 0) return bprm->argc; =20 @@ -482,8 +485,14 @@ static int prepare_arg_pages(struct linu * the stack. They aren't stored until much later when we can't * signal to the parent that the child has run out of stack space. * Instead, calculate it here so it's possible to fail gracefully. + * + * In the case of argc =3D 0, make sure there is space for adding a + * empty string (which will bump argc to 1), to ensure confused + * userspace programs don't start processing from argv[1], thinking + * argc can never be 0, to keep them from walking envp by accident. + * See do_execveat_common(). */ - ptr_size =3D (bprm->argc + bprm->envc) * sizeof(void *); + ptr_size =3D (max(bprm->argc, 1) + bprm->envc) * sizeof(void *); if (limit <=3D ptr_size) return -E2BIG; limit -=3D ptr_size; @@ -1848,6 +1857,20 @@ static int __do_execve_file(int fd, stru if (retval < 0) goto out; =20 + /* + * When argv is empty, add an empty string ("") as argv[0] to + * ensure confused userspace programs that start processing + * from argv[1] won't end up walking envp. See also + * bprm_stack_limits(). + */ + if (bprm->argc =3D=3D 0) { + const char *argv[] =3D { "", NULL }; + retval =3D copy_strings_kernel(1, argv, bprm); + if (retval < 0) + goto out; + bprm->argc =3D 1; + } + retval =3D exec_binprm(bprm); if (retval < 0) goto out; From nobody Tue Apr 28 06:24:51 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 60612C43334 for ; Fri, 3 Jun 2022 17:52:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345562AbiFCRuA (ORCPT ); Fri, 3 Jun 2022 13:50:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46474 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345350AbiFCRsL (ORCPT ); Fri, 3 Jun 2022 13:48:11 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D87D153E01; Fri, 3 Jun 2022 10:44:57 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 8423AB82430; Fri, 3 Jun 2022 17:44:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DF5E3C385A9; Fri, 3 Jun 2022 17:44:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278295; bh=7yMpx/p4JIbj1RxSrsvc4F7sy+yL65SQaQLr9b7p4J4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=gEX7s9X8sgcnspPq0QeRyZy8MfrKcOli6q0y4nMbXs3ZdKL/VO8nCWQ7U+w6ix4t3 snowuvI3NDN5oPc/wLiVeoCa4qrgfcb2uw+q1HGlSwazWaUZ+AzKyTCMs5GxVljLeI rHY7rLVLAB0PmN7jtwiZyZDs4lByI/7iSskFULf4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, syzbot+793a590957d9c1b96620@syzkaller.appspotmail.com, Florian Westphal , Pablo Neira Ayuso Subject: [PATCH 5.4 20/34] netfilter: conntrack: re-fetch conntrack after insertion Date: Fri, 3 Jun 2022 19:43:16 +0200 Message-Id: <20220603173816.580122789@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173815.990072516@linuxfoundation.org> References: <20220603173815.990072516@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Florian Westphal commit 56b14ecec97f39118bf85c9ac2438c5a949509ed upstream. In case the conntrack is clashing, insertion can free skb->_nfct and set skb->_nfct to the already-confirmed entry. This wasn't found before because the conntrack entry and the extension space used to free'd after an rcu grace period, plus the race needs events enabled to trigger. Reported-by: Fixes: 71d8c47fc653 ("netfilter: conntrack: introduce clash resolution on i= nsertion race") Fixes: 2ad9d7747c10 ("netfilter: conntrack: free extension area immediately= ") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee --- include/net/netfilter/nf_conntrack_core.h | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) --- a/include/net/netfilter/nf_conntrack_core.h +++ b/include/net/netfilter/nf_conntrack_core.h @@ -59,8 +59,13 @@ static inline int nf_conntrack_confirm(s int ret =3D NF_ACCEPT; =20 if (ct) { - if (!nf_ct_is_confirmed(ct)) + if (!nf_ct_is_confirmed(ct)) { ret =3D __nf_conntrack_confirm(skb); + + if (ret =3D=3D NF_ACCEPT) + ct =3D (struct nf_conn *)skb_nfct(skb); + } + if (likely(ret =3D=3D NF_ACCEPT)) nf_ct_deliver_cached_events(ct); } From nobody Tue Apr 28 06:24:51 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id AC366C433EF for ; Fri, 3 Jun 2022 17:52:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345483AbiFCRtz (ORCPT ); Fri, 3 Jun 2022 13:49:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46318 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345357AbiFCRsL (ORCPT ); Fri, 3 Jun 2022 13:48:11 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A9EA253E05; Fri, 3 Jun 2022 10:45:00 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 6BBE4B82430; Fri, 3 Jun 2022 17:44:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BB7F6C385A9; Fri, 3 Jun 2022 17:44:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278298; bh=JRlXN+QbL40CRn9Cwv7aCRqGZNOb6OjwTpt42fLYcMk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=esNiSIDpMjzKWdJUlsPeQsQCEH6REuZV7ZcAr5qg59BqYgYfApa7YVYwvQi+EVUle ZEnKSwXdfq7nXoRSK1G4UraUutuI5TpryJLoCcOFbVQREjvKD3veP+PuBK0TnON09w 6/Rrw8rhFAtqiOuQ6V7ELsJEGNK75ikkELg2rmKQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Vitaly Chikunov , Herbert Xu Subject: [PATCH 5.4 21/34] crypto: ecrdsa - Fix incorrect use of vli_cmp Date: Fri, 3 Jun 2022 19:43:17 +0200 Message-Id: <20220603173816.609143086@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173815.990072516@linuxfoundation.org> References: <20220603173815.990072516@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Vitaly Chikunov commit 7cc7ab73f83ee6d50dc9536bc3355495d8600fad upstream. Correctly compare values that shall be greater-or-equal and not just greater. Fixes: 0d7a78643f69 ("crypto: ecrdsa - add EC-RDSA (GOST 34.10) algorithm") Cc: Signed-off-by: Vitaly Chikunov Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee --- crypto/ecrdsa.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) --- a/crypto/ecrdsa.c +++ b/crypto/ecrdsa.c @@ -112,15 +112,15 @@ static int ecrdsa_verify(struct akcipher =20 /* Step 1: verify that 0 < r < q, 0 < s < q */ if (vli_is_zero(r, ndigits) || - vli_cmp(r, ctx->curve->n, ndigits) =3D=3D 1 || + vli_cmp(r, ctx->curve->n, ndigits) >=3D 0 || vli_is_zero(s, ndigits) || - vli_cmp(s, ctx->curve->n, ndigits) =3D=3D 1) + vli_cmp(s, ctx->curve->n, ndigits) >=3D 0) return -EKEYREJECTED; =20 /* Step 2: calculate hash (h) of the message (passed as input) */ /* Step 3: calculate e =3D h \mod q */ vli_from_le64(e, digest, ndigits); - if (vli_cmp(e, ctx->curve->n, ndigits) =3D=3D 1) + if (vli_cmp(e, ctx->curve->n, ndigits) >=3D 0) vli_sub(e, e, ctx->curve->n, ndigits); if (vli_is_zero(e, ndigits)) e[0] =3D 1; @@ -136,7 +136,7 @@ static int ecrdsa_verify(struct akcipher /* Step 6: calculate point C =3D z_1P + z_2Q, and R =3D x_c \mod q */ ecc_point_mult_shamir(&cc, z1, &ctx->curve->g, z2, &ctx->pub_key, ctx->curve); - if (vli_cmp(cc.x, ctx->curve->n, ndigits) =3D=3D 1) + if (vli_cmp(cc.x, ctx->curve->n, ndigits) >=3D 0) vli_sub(cc.x, cc.x, ctx->curve->n, ndigits); =20 /* Step 7: if R =3D=3D r signature is valid */ From nobody Tue Apr 28 06:24:51 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C1B64C43334 for ; Fri, 3 Jun 2022 17:52:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345532AbiFCRt6 (ORCPT ); Fri, 3 Jun 2022 13:49:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46572 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345277AbiFCRsL (ORCPT ); Fri, 3 Jun 2022 13:48:11 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 067C253A65; Fri, 3 Jun 2022 10:45:02 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 97C2A604EF; Fri, 3 Jun 2022 17:45:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9E055C385B8; Fri, 3 Jun 2022 17:45:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278301; bh=V/yGTt7Ocp4ajWdl5FHnoH8c4RKdCJlTJGqL+no4af0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=0mvb+YlmmNtBfl3eFiqOvjuvnPwV23b88VzjLEojufnkJDtz3YxwI26rD5V2NdtoS ibsdmtBWIAPhtHJ/cNcxtG2go+LUggYfCWF8pVE2cDzwSAacSqkuvC4XvztmBOyBY5 DfcH5bfhRVeaE1P6lMo7Ot/Wau1lGAuj5nBcVZq0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Sultan Alsawaf , Minchan Kim , Nitin Gupta , Sergey Senozhatsky , Andrew Morton Subject: [PATCH 5.4 22/34] zsmalloc: fix races between asynchronous zspage free and page migration Date: Fri, 3 Jun 2022 19:43:18 +0200 Message-Id: <20220603173816.638262170@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173815.990072516@linuxfoundation.org> References: <20220603173815.990072516@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Sultan Alsawaf commit 2505a981114dcb715f8977b8433f7540854851d8 upstream. The asynchronous zspage free worker tries to lock a zspage's entire page list without defending against page migration. Since pages which haven't yet been locked can concurrently migrate off the zspage page list while lock_zspage() churns away, lock_zspage() can suffer from a few different lethal races. It can lock a page which no longer belongs to the zspage and unsafely dereference page_private(), it can unsafely dereference a torn pointer to the next page (since there's a data race), and it can observe a spurious NULL pointer to the next page and thus not lock all of the zspage's pages (since a single page migration will reconstruct the entire page list, and create_page_chain() unconditionally zeroes out each list pointer in the process). Fix the races by using migrate_read_lock() in lock_zspage() to synchronize with page migration. Link: https://lkml.kernel.org/r/20220509024703.243847-1-sultan@kerneltoast.= com Fixes: 77ff465799c602 ("zsmalloc: zs_page_migrate: skip unnecessary loops b= ut not return -EBUSY if zspage is not inuse") Signed-off-by: Sultan Alsawaf Acked-by: Minchan Kim Cc: Nitin Gupta Cc: Sergey Senozhatsky Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee --- mm/zsmalloc.c | 37 +++++++++++++++++++++++++++++++++---- 1 file changed, 33 insertions(+), 4 deletions(-) --- a/mm/zsmalloc.c +++ b/mm/zsmalloc.c @@ -1748,11 +1748,40 @@ static enum fullness_group putback_zspag */ static void lock_zspage(struct zspage *zspage) { - struct page *page =3D get_first_page(zspage); + struct page *curr_page, *page; =20 - do { - lock_page(page); - } while ((page =3D get_next_page(page)) !=3D NULL); + /* + * Pages we haven't locked yet can be migrated off the list while we're + * trying to lock them, so we need to be careful and only attempt to + * lock each page under migrate_read_lock(). Otherwise, the page we lock + * may no longer belong to the zspage. This means that we may wait for + * the wrong page to unlock, so we must take a reference to the page + * prior to waiting for it to unlock outside migrate_read_lock(). + */ + while (1) { + migrate_read_lock(zspage); + page =3D get_first_page(zspage); + if (trylock_page(page)) + break; + get_page(page); + migrate_read_unlock(zspage); + wait_on_page_locked(page); + put_page(page); + } + + curr_page =3D page; + while ((page =3D get_next_page(curr_page))) { + if (trylock_page(page)) { + curr_page =3D page; + } else { + get_page(page); + migrate_read_unlock(zspage); + wait_on_page_locked(page); + put_page(page); + migrate_read_lock(zspage); + } + } + migrate_read_unlock(zspage); } =20 static int zs_init_fs_context(struct fs_context *fc) From nobody Tue Apr 28 06:24:51 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3EBA9C43334 for ; Fri, 3 Jun 2022 17:49:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345448AbiFCRtq (ORCPT ); Fri, 3 Jun 2022 13:49:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44642 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345362AbiFCRsN (ORCPT ); Fri, 3 Jun 2022 13:48:13 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 378BA54188; Fri, 3 Jun 2022 10:45:05 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id BCC3460A0F; Fri, 3 Jun 2022 17:45:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C16DEC385A9; Fri, 3 Jun 2022 17:45:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278304; bh=McbMbDm5n1vM5bMSXRjPzQihuWBuTHSYTtFHdq3qsro=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=tW5EftI0hnelnX6co6/IXHJYrCfrwIBuOuBZOP7pp7hlYmJEjKEbB2D+3KBKQ7mBw MBvT42loB0CtShxEpiA1ODcgRNrRMIzBjP1bJJIV8eVswDQ3K5qz20Em/rdv/mh04t XdkkPyMJPTMs9YrEWB/c2blx7sohxku6pdu6fQwY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Dan Carpenter , Mikulas Patocka , Mike Snitzer Subject: [PATCH 5.4 23/34] dm integrity: fix error code in dm_integrity_ctr() Date: Fri, 3 Jun 2022 19:43:19 +0200 Message-Id: <20220603173816.666898118@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173815.990072516@linuxfoundation.org> References: <20220603173815.990072516@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Dan Carpenter commit d3f2a14b8906df913cb04a706367b012db94a6e8 upstream. The "r" variable shadows an earlier "r" that has function scope. It means that we accidentally return success instead of an error code. Smatch has a warning for this: drivers/md/dm-integrity.c:4503 dm_integrity_ctr() warn: missing error code 'r' Fixes: 7eada909bfd7 ("dm: add integrity target") Cc: stable@vger.kernel.org Signed-off-by: Dan Carpenter Reviewed-by: Mikulas Patocka Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee --- drivers/md/dm-integrity.c | 2 -- 1 file changed, 2 deletions(-) --- a/drivers/md/dm-integrity.c +++ b/drivers/md/dm-integrity.c @@ -4149,8 +4149,6 @@ try_smaller_buffer: } =20 if (should_write_sb) { - int r; - init_journal(ic, 0, ic->journal_sections, 0); r =3D dm_integrity_failed(ic); if (unlikely(r)) { From nobody Tue Apr 28 06:24:51 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id AF217C433EF for ; Fri, 3 Jun 2022 17:52:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345398AbiFCRtu (ORCPT ); Fri, 3 Jun 2022 13:49:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46560 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237724AbiFCRsN (ORCPT ); Fri, 3 Jun 2022 13:48:13 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A2A855418C; Fri, 3 Jun 2022 10:45:09 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 4FCC7B82419; Fri, 3 Jun 2022 17:45:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C1743C385A9; Fri, 3 Jun 2022 17:45:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278307; bh=9PFnQ6U/pODrMpclM6aw2q4n7Wt6WMpJbMXQn9a3ZHg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=CKL14HomZ2Eq7xpeX1aBiL8lHKjGRfLlpAB9Z5/+VNmtXiwKldKQXmqITIlWO498h zpRHtqvYgCMiq8rtUmoejSMpTqHKArpoXoNPhMWjoVeOqGwZxSaXMow6SaEFu7WY57 lQYBO6oNOevKGt8BnO84kmw7cZabNLDdpx42q+zM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Mikulas Patocka , Milan Broz , Mike Snitzer Subject: [PATCH 5.4 24/34] dm crypt: make printing of the key constant-time Date: Fri, 3 Jun 2022 19:43:20 +0200 Message-Id: <20220603173816.695539048@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173815.990072516@linuxfoundation.org> References: <20220603173815.990072516@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Mikulas Patocka commit 567dd8f34560fa221a6343729474536aa7ede4fd upstream. The device mapper dm-crypt target is using scnprintf("%02x", cc->key[i]) to report the current key to userspace. However, this is not a constant-time operation and it may leak information about the key via timing, via cache access patterns or via the branch predictor. Change dm-crypt's key printing to use "%c" instead of "%02x". Also introduce hex2asc() that carefully avoids any branching or memory accesses when converting a number in the range 0 ... 15 to an ascii character. Cc: stable@vger.kernel.org Signed-off-by: Mikulas Patocka Tested-by: Milan Broz Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee --- drivers/md/dm-crypt.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) --- a/drivers/md/dm-crypt.c +++ b/drivers/md/dm-crypt.c @@ -2817,6 +2817,11 @@ static int crypt_map(struct dm_target *t return DM_MAPIO_SUBMITTED; } =20 +static char hex2asc(unsigned char c) +{ + return c + '0' + ((unsigned)(9 - c) >> 4 & 0x27); +} + static void crypt_status(struct dm_target *ti, status_type_t type, unsigned status_flags, char *result, unsigned maxlen) { @@ -2835,9 +2840,12 @@ static void crypt_status(struct dm_targe if (cc->key_size > 0) { if (cc->key_string) DMEMIT(":%u:%s", cc->key_size, cc->key_string); - else - for (i =3D 0; i < cc->key_size; i++) - DMEMIT("%02x", cc->key[i]); + else { + for (i =3D 0; i < cc->key_size; i++) { + DMEMIT("%c%c", hex2asc(cc->key[i] >> 4), + hex2asc(cc->key[i] & 0xf)); + } + } } else DMEMIT("-"); From nobody Tue Apr 28 06:24:51 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9D8A6C433EF for ; Fri, 3 Jun 2022 17:49:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345267AbiFCRtF (ORCPT ); Fri, 3 Jun 2022 13:49:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44732 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345368AbiFCRsN (ORCPT ); Fri, 3 Jun 2022 13:48:13 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E821B5418F; Fri, 3 Jun 2022 10:45:10 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 859E660A0F; Fri, 3 Jun 2022 17:45:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8E10DC385B8; Fri, 3 Jun 2022 17:45:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278310; bh=NnEyWjMihEvGC1ycsFdaXgQ+EWmAJe/cwgy1WOjErkM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=mSUZdAoPym97KU2ubp9gK3epjmL9A90oRf7BVhKakGAsuDq/hOQPnVxqeoq95pumc puPQSl7VJC4KkMcrehfb3gGYhInEPiFvnXok9l7cDTa1cAusKKbl9z3BTQD/7Mj1n6 KRXaPbaSnvd8kcKY0+zmqqeduT9y7lWK3zLmNa4w= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Mikulas Patocka , Mike Snitzer Subject: [PATCH 5.4 25/34] dm stats: add cond_resched when looping over entries Date: Fri, 3 Jun 2022 19:43:21 +0200 Message-Id: <20220603173816.915846548@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173815.990072516@linuxfoundation.org> References: <20220603173815.990072516@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Mikulas Patocka commit bfe2b0146c4d0230b68f5c71a64380ff8d361f8b upstream. dm-stats can be used with a very large number of entries (it is only limited by 1/4 of total system memory), so add rescheduling points to the loops that iterate over the entries. Cc: stable@vger.kernel.org Signed-off-by: Mikulas Patocka Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee --- drivers/md/dm-stats.c | 8 ++++++++ 1 file changed, 8 insertions(+) --- a/drivers/md/dm-stats.c +++ b/drivers/md/dm-stats.c @@ -224,6 +224,7 @@ void dm_stats_cleanup(struct dm_stats *s atomic_read(&shared->in_flight[READ]), atomic_read(&shared->in_flight[WRITE])); } + cond_resched(); } dm_stat_free(&s->rcu_head); } @@ -313,6 +314,7 @@ static int dm_stats_create(struct dm_sta for (ni =3D 0; ni < n_entries; ni++) { atomic_set(&s->stat_shared[ni].in_flight[READ], 0); atomic_set(&s->stat_shared[ni].in_flight[WRITE], 0); + cond_resched(); } =20 if (s->n_histogram_entries) { @@ -325,6 +327,7 @@ static int dm_stats_create(struct dm_sta for (ni =3D 0; ni < n_entries; ni++) { s->stat_shared[ni].tmp.histogram =3D hi; hi +=3D s->n_histogram_entries + 1; + cond_resched(); } } =20 @@ -345,6 +348,7 @@ static int dm_stats_create(struct dm_sta for (ni =3D 0; ni < n_entries; ni++) { p[ni].histogram =3D hi; hi +=3D s->n_histogram_entries + 1; + cond_resched(); } } } @@ -474,6 +478,7 @@ static int dm_stats_list(struct dm_stats } DMEMIT("\n"); } + cond_resched(); } mutex_unlock(&stats->mutex); =20 @@ -750,6 +755,7 @@ static void __dm_stat_clear(struct dm_st local_irq_enable(); } } + cond_resched(); } } =20 @@ -865,6 +871,8 @@ static int dm_stats_print(struct dm_stat =20 if (unlikely(sz + 1 >=3D maxlen)) goto buffer_overflow; + + cond_resched(); } =20 if (clear) From nobody Tue Apr 28 06:24:51 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5F23FC43334 for ; Fri, 3 Jun 2022 17:49:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345292AbiFCRtN (ORCPT ); Fri, 3 Jun 2022 13:49:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44936 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345301AbiFCRsN (ORCPT ); Fri, 3 Jun 2022 13:48:13 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6DE6E5419E; Fri, 3 Jun 2022 10:45:15 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 2B5E6B8241E; Fri, 3 Jun 2022 17:45:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8F62FC385B8; Fri, 3 Jun 2022 17:45:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278312; bh=47f7J/bvqDmwI8W51pEpNDULYt1Cvzwange2OEDeQes=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=T/CdcPna1r37hO6SWu8/MF86llSCejlqO8zNLN6l7VbCP0ZrtmlhNtKz5KhR46S3c kIy5nECZCOyQ7/z5ocL8tr7sut4VPWI4/PaOsPTfgOFYLHuq9pS56uxFnEz93vFpiw 0jU+5wo9CPt2Rn3yyfoxRbeC6siovqHajTtH/GtU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Sarthak Kukreti , Kees Cook , Mike Snitzer Subject: [PATCH 5.4 26/34] dm verity: set DM_TARGET_IMMUTABLE feature flag Date: Fri, 3 Jun 2022 19:43:22 +0200 Message-Id: <20220603173816.944766454@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173815.990072516@linuxfoundation.org> References: <20220603173815.990072516@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Sarthak Kukreti commit 4caae58406f8ceb741603eee460d79bacca9b1b5 upstream. The device-mapper framework provides a mechanism to mark targets as immutable (and hence fail table reloads that try to change the target type). Add the DM_TARGET_IMMUTABLE flag to the dm-verity target's feature flags to prevent switching the verity target with a different target type. Fixes: a4ffc152198e ("dm: add verity target") Cc: stable@vger.kernel.org Signed-off-by: Sarthak Kukreti Reviewed-by: Kees Cook Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee --- drivers/md/dm-verity-target.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/md/dm-verity-target.c +++ b/drivers/md/dm-verity-target.c @@ -1217,6 +1217,7 @@ bad: =20 static struct target_type verity_target =3D { .name =3D "verity", + .features =3D DM_TARGET_IMMUTABLE, .version =3D {1, 5, 0}, .module =3D THIS_MODULE, .ctr =3D verity_ctr, From nobody Tue Apr 28 06:24:51 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A0766C43334 for ; Fri, 3 Jun 2022 17:49:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345283AbiFCRtQ (ORCPT ); Fri, 3 Jun 2022 13:49:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45562 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345382AbiFCRsN (ORCPT ); Fri, 3 Jun 2022 13:48:13 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 68417541A5; Fri, 3 Jun 2022 10:45:18 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id F3FD1B82189; Fri, 3 Jun 2022 17:45:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6FB21C385A9; Fri, 3 Jun 2022 17:45:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278315; bh=RfqyOJ1f3vwsJ/l8aXseJ5uaPsZQziWS6rcM28tJ7Uw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=rx3sRJEw11qlagPHUmQK+/DqMTYxZLMWTSzHentd27XWCDDjwLXpcs1N2w0Q71S64 UhMAL2kb3gtdH9soUDwEjmMkmf0KM/oKTwaIRCuE2a1ugbCIAYA8Z8QBF7LStrnJK+ gm62HzZ/Ilvf4ulmuiy8w8AEWVHcQ7mLrIeXVuC0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Mariusz Tkaczyk , Song Liu , Xiao Ni Subject: [PATCH 5.4 27/34] raid5: introduce MD_BROKEN Date: Fri, 3 Jun 2022 19:43:23 +0200 Message-Id: <20220603173816.972587698@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173815.990072516@linuxfoundation.org> References: <20220603173815.990072516@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Mariusz Tkaczyk commit 57668f0a4cc4083a120cc8c517ca0055c4543b59 upstream. Raid456 module had allowed to achieve failed state. It was fixed by fb73b357fb9 ("raid5: block failing device if raid will be failed"). This fix introduces a bug, now if raid5 fails during IO, it may result with a hung task without completion. Faulty flag on the device is necessary to process all requests and is checked many times, mainly in analyze_stripe(). Allow to set faulty on drive again and set MD_BROKEN if raid is failed. As a result, this level is allowed to achieve failed state again, but communication with userspace (via -EBUSY status) will be preserved. This restores possibility to fail array via #mdadm --set-faulty command and will be fixed by additional verification on mdadm side. Reproduction steps: mdadm -CR imsm -e imsm -n 3 /dev/nvme[0-2]n1 mdadm -CR r5 -e imsm -l5 -n3 /dev/nvme[0-2]n1 --assume-clean mkfs.xfs /dev/md126 -f mount /dev/md126 /mnt/root/ fio --filename=3D/mnt/root/file --size=3D5GB --direct=3D1 --rw=3Drandrw --bs=3D64k --ioengine=3Dlibaio --iodepth=3D64 --runtime=3D240 --numjobs=3D4 --time_based --group_reporting --name=3Dthroughput-test-job --eta-newline=3D1 & echo 1 > /sys/block/nvme2n1/device/device/remove echo 1 > /sys/block/nvme1n1/device/device/remove [ 1475.787779] Call Trace: [ 1475.793111] __schedule+0x2a6/0x700 [ 1475.799460] schedule+0x38/0xa0 [ 1475.805454] raid5_get_active_stripe+0x469/0x5f0 [raid456] [ 1475.813856] ? finish_wait+0x80/0x80 [ 1475.820332] raid5_make_request+0x180/0xb40 [raid456] [ 1475.828281] ? finish_wait+0x80/0x80 [ 1475.834727] ? finish_wait+0x80/0x80 [ 1475.841127] ? finish_wait+0x80/0x80 [ 1475.847480] md_handle_request+0x119/0x190 [ 1475.854390] md_make_request+0x8a/0x190 [ 1475.861041] generic_make_request+0xcf/0x310 [ 1475.868145] submit_bio+0x3c/0x160 [ 1475.874355] iomap_dio_submit_bio.isra.20+0x51/0x60 [ 1475.882070] iomap_dio_bio_actor+0x175/0x390 [ 1475.889149] iomap_apply+0xff/0x310 [ 1475.895447] ? iomap_dio_bio_actor+0x390/0x390 [ 1475.902736] ? iomap_dio_bio_actor+0x390/0x390 [ 1475.909974] iomap_dio_rw+0x2f2/0x490 [ 1475.916415] ? iomap_dio_bio_actor+0x390/0x390 [ 1475.923680] ? atime_needs_update+0x77/0xe0 [ 1475.930674] ? xfs_file_dio_aio_read+0x6b/0xe0 [xfs] [ 1475.938455] xfs_file_dio_aio_read+0x6b/0xe0 [xfs] [ 1475.946084] xfs_file_read_iter+0xba/0xd0 [xfs] [ 1475.953403] aio_read+0xd5/0x180 [ 1475.959395] ? _cond_resched+0x15/0x30 [ 1475.965907] io_submit_one+0x20b/0x3c0 [ 1475.972398] __x64_sys_io_submit+0xa2/0x180 [ 1475.979335] ? do_io_getevents+0x7c/0xc0 [ 1475.986009] do_syscall_64+0x5b/0x1a0 [ 1475.992419] entry_SYSCALL_64_after_hwframe+0x65/0xca [ 1476.000255] RIP: 0033:0x7f11fc27978d [ 1476.006631] Code: Bad RIP value. [ 1476.073251] INFO: task fio:3877 blocked for more than 120 seconds. Cc: stable@vger.kernel.org Fixes: fb73b357fb9 ("raid5: block failing device if raid will be failed") Reviewd-by: Xiao Ni Signed-off-by: Mariusz Tkaczyk Signed-off-by: Song Liu Signed-off-by: Greg Kroah-Hartman Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee --- drivers/md/raid5.c | 47 ++++++++++++++++++++++------------------------- 1 file changed, 22 insertions(+), 25 deletions(-) --- a/drivers/md/raid5.c +++ b/drivers/md/raid5.c @@ -609,17 +609,17 @@ int raid5_calc_degraded(struct r5conf *c return degraded; } =20 -static int has_failed(struct r5conf *conf) +static bool has_failed(struct r5conf *conf) { - int degraded; + int degraded =3D conf->mddev->degraded; =20 - if (conf->mddev->reshape_position =3D=3D MaxSector) - return conf->mddev->degraded > conf->max_degraded; + if (test_bit(MD_BROKEN, &conf->mddev->flags)) + return true; =20 - degraded =3D raid5_calc_degraded(conf); - if (degraded > conf->max_degraded) - return 1; - return 0; + if (conf->mddev->reshape_position !=3D MaxSector) + degraded =3D raid5_calc_degraded(conf); + + return degraded > conf->max_degraded; } =20 struct stripe_head * @@ -2679,34 +2679,31 @@ static void raid5_error(struct mddev *md unsigned long flags; pr_debug("raid456: error called\n"); =20 + pr_crit("md/raid:%s: Disk failure on %s, disabling device.\n", + mdname(mddev), bdevname(rdev->bdev, b)); + spin_lock_irqsave(&conf->device_lock, flags); + set_bit(Faulty, &rdev->flags); + clear_bit(In_sync, &rdev->flags); + mddev->degraded =3D raid5_calc_degraded(conf); =20 - if (test_bit(In_sync, &rdev->flags) && - mddev->degraded =3D=3D conf->max_degraded) { - /* - * Don't allow to achieve failed state - * Don't try to recover this device - */ + if (has_failed(conf)) { + set_bit(MD_BROKEN, &conf->mddev->flags); conf->recovery_disabled =3D mddev->recovery_disabled; - spin_unlock_irqrestore(&conf->device_lock, flags); - return; + + pr_crit("md/raid:%s: Cannot continue operation (%d/%d failed).\n", + mdname(mddev), mddev->degraded, conf->raid_disks); + } else { + pr_crit("md/raid:%s: Operation continuing on %d devices.\n", + mdname(mddev), conf->raid_disks - mddev->degraded); } =20 - set_bit(Faulty, &rdev->flags); - clear_bit(In_sync, &rdev->flags); - mddev->degraded =3D raid5_calc_degraded(conf); spin_unlock_irqrestore(&conf->device_lock, flags); set_bit(MD_RECOVERY_INTR, &mddev->recovery); =20 set_bit(Blocked, &rdev->flags); set_mask_bits(&mddev->sb_flags, 0, BIT(MD_SB_CHANGE_DEVS) | BIT(MD_SB_CHANGE_PENDING)); - pr_crit("md/raid:%s: Disk failure on %s, disabling device.\n" - "md/raid:%s: Operation continuing on %d devices.\n", - mdname(mddev), - bdevname(rdev->bdev, b), - mdname(mddev), - conf->raid_disks - mddev->degraded); r5c_update_on_rdev_error(mddev, rdev); } From nobody Tue Apr 28 06:24:51 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id AE457C433EF for ; Fri, 3 Jun 2022 17:49:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345324AbiFCRtW (ORCPT ); Fri, 3 Jun 2022 13:49:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44704 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345384AbiFCRsN (ORCPT ); Fri, 3 Jun 2022 13:48:13 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 84D5E541B5; Fri, 3 Jun 2022 10:45:22 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 03FE460A24; Fri, 3 Jun 2022 17:45:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 12289C385A9; Fri, 3 Jun 2022 17:45:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278321; bh=+w66Ow9xeA7Z0WMgKSy5y2U7WP4p9tUaCId1oFEUwl8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ob8X5VSh0Kk9LMm4OgVaNf599adh4+GHlV69H+Jfacfcx/Xs6GYZxsYd+g9+1xoDh lFYy950V7gJo2z1YpRbjsNg0YsV+6criF2SS+uPKogNKk8ieFrueCcaBBBzXRE33JG +KF9yY3bVr1HMu7NUMYWwiRaMM9Ta0NFYJMTjs+8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Marek Maslanka , Benjamin Tissoires , Jiri Kosina Subject: [PATCH 5.4 28/34] HID: multitouch: Add support for Google Whiskers Touchpad Date: Fri, 3 Jun 2022 19:43:24 +0200 Message-Id: <20220603173817.000712172@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173815.990072516@linuxfoundation.org> References: <20220603173815.990072516@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Marek Ma=C5=9Blanka commit 1d07cef7fd7599450b3d03e1915efc2a96e1f03f upstream. The Google Whiskers touchpad does not work properly with the default multitouch configuration. Instead, use the same configuration as Google Rose. Signed-off-by: Marek Maslanka Acked-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee --- drivers/hid/hid-multitouch.c | 3 +++ 1 file changed, 3 insertions(+) --- a/drivers/hid/hid-multitouch.c +++ b/drivers/hid/hid-multitouch.c @@ -2158,6 +2158,9 @@ static const struct hid_device_id mt_dev { .driver_data =3D MT_CLS_GOOGLE, HID_DEVICE(HID_BUS_ANY, HID_GROUP_ANY, USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_TOUCH_ROSE) }, + { .driver_data =3D MT_CLS_GOOGLE, + HID_DEVICE(BUS_USB, HID_GROUP_MULTITOUCH_WIN_8, USB_VENDOR_ID_GOOGLE, + USB_DEVICE_ID_GOOGLE_WHISKERS) }, =20 /* Generic MT device */ { HID_DEVICE(HID_BUS_ANY, HID_GROUP_MULTITOUCH, HID_ANY_ID, HID_ANY_ID) }, From nobody Tue Apr 28 06:24:51 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4D935C43334 for ; Fri, 3 Jun 2022 17:49:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345433AbiFCRtk (ORCPT ); Fri, 3 Jun 2022 13:49:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44786 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345004AbiFCRsU (ORCPT ); Fri, 3 Jun 2022 13:48:20 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DF185541AA; Fri, 3 Jun 2022 10:45:24 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 7C25A60A6B; Fri, 3 Jun 2022 17:45:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8CB3BC385B8; Fri, 3 Jun 2022 17:45:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278323; bh=e1GvVuGQ+unzosyZcj6xC7FjpppfWqxA/blqXv1Kyd4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=faVpcDpdOgk7m2EIL3xxanoDyuwZWeSsd+calvMaG0P7GpQSTXgmEA4vBb199+EB/ ekf8C3fSsr/YIJooKRhHk8toGdZH4jV5r2bX2QWL0RKAIhBDsbsmoZj8yg8dnaSdwA AqAnloLn8Qh7vlqnizWLbkyC5cTVeY0CEuNFfv3Q= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Stefan Mahnke-Hartmann , Jarkko Sakkinen Subject: [PATCH 5.4 29/34] tpm: Fix buffer access in tpm2_get_tpm_pt() Date: Fri, 3 Jun 2022 19:43:25 +0200 Message-Id: <20220603173817.028616126@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173815.990072516@linuxfoundation.org> References: <20220603173815.990072516@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Stefan Mahnke-Hartmann commit e57b2523bd37e6434f4e64c7a685e3715ad21e9a upstream. Under certain conditions uninitialized memory will be accessed. As described by TCG Trusted Platform Module Library Specification, rev. 1.59 (Part 3: Commands), if a TPM2_GetCapability is received, requesting a capability, the TPM in field upgrade mode may return a zero length list. Check the property count in tpm2_get_tpm_pt(). Fixes: 2ab3241161b3 ("tpm: migrate tpm2_get_tpm_pt() to use struct tpm_buf") Cc: stable@vger.kernel.org Signed-off-by: Stefan Mahnke-Hartmann Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee --- drivers/char/tpm/tpm2-cmd.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) --- a/drivers/char/tpm/tpm2-cmd.c +++ b/drivers/char/tpm/tpm2-cmd.c @@ -706,7 +706,16 @@ ssize_t tpm2_get_tpm_pt(struct tpm_chip if (!rc) { out =3D (struct tpm2_get_cap_out *) &buf.data[TPM_HEADER_SIZE]; - *value =3D be32_to_cpu(out->value); + /* + * To prevent failing boot up of some systems, Infineon TPM2.0 + * returns SUCCESS on TPM2_Startup in field upgrade mode. Also + * the TPM2_Getcapability command returns a zero length list + * in field upgrade mode. + */ + if (be32_to_cpu(out->property_cnt) > 0) + *value =3D be32_to_cpu(out->value); + else + rc =3D -ENODATA; } tpm_buf_destroy(&buf); return rc; From nobody Tue Apr 28 06:24:51 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B6B2DC43334 for ; Fri, 3 Jun 2022 17:49:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345423AbiFCRtc (ORCPT ); Fri, 3 Jun 2022 13:49:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44962 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345204AbiFCRsV (ORCPT ); Fri, 3 Jun 2022 13:48:21 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E43FA541B0; Fri, 3 Jun 2022 10:45:27 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 7D025604EF; Fri, 3 Jun 2022 17:45:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 89376C3411D; Fri, 3 Jun 2022 17:45:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278326; bh=sZ4yllEhtH7VW3/c5dkMAKfZGAOTfmyEplEGryc4wQ8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=nLHT/RZBbxA5chvwb0/YSUuFOK5A2Cu08iuo9MtWJuQUo9ewE7x6f+OyPGYbcmOlM O0Dc7qzxSjIiHKcyIzUSBSZ8kvaIiNq8WydCyxCr/SN+3QZXl1UPBGXnAgnEEA3Mpy EaXBm7QIHmFbyotZhhN+0RqQtLvwwFt7Dw36eEDY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Xiu Jianfeng , Stefan Berger , Jarkko Sakkinen Subject: [PATCH 5.4 30/34] tpm: ibmvtpm: Correct the return value in tpm_ibmvtpm_probe() Date: Fri, 3 Jun 2022 19:43:26 +0200 Message-Id: <20220603173817.057325274@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173815.990072516@linuxfoundation.org> References: <20220603173815.990072516@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Xiu Jianfeng commit d0dc1a7100f19121f6e7450f9cdda11926aa3838 upstream. Currently it returns zero when CRQ response timed out, it should return an error code instead. Fixes: d8d74ea3c002 ("tpm: ibmvtpm: Wait for buffer to be set before procee= ding") Signed-off-by: Xiu Jianfeng Reviewed-by: Stefan Berger Acked-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee --- drivers/char/tpm/tpm_ibmvtpm.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/char/tpm/tpm_ibmvtpm.c +++ b/drivers/char/tpm/tpm_ibmvtpm.c @@ -685,6 +685,7 @@ static int tpm_ibmvtpm_probe(struct vio_ if (!wait_event_timeout(ibmvtpm->crq_queue.wq, ibmvtpm->rtce_buf !=3D NULL, HZ)) { + rc =3D -ENODEV; dev_err(dev, "CRQ response timed out\n"); goto init_irq_cleanup; } From nobody Tue Apr 28 06:24:51 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 80CD3C43334 for ; Fri, 3 Jun 2022 17:52:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231362AbiFCRwU (ORCPT ); Fri, 3 Jun 2022 13:52:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46420 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345325AbiFCRss (ORCPT ); Fri, 3 Jun 2022 13:48:48 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 77E2854684; Fri, 3 Jun 2022 10:45:32 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 0A886B82189; Fri, 3 Jun 2022 17:45:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6840EC385A9; Fri, 3 Jun 2022 17:45:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278329; bh=feL5DhGpFr9fOQ+CVlQslnoobzfhYmtKXTcaAR7THEI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SYPCZ5+9y/g3/Yj233yH0AjuZCvctGhChGIGr4bsjzs8qOXreEd9C1EXeApwkOBja sxTlUc28ifGeIQ3zty69IfDc1v6JWuO2sajftkcHPgra5ExjGd1wh+R3NXG0ty8IXh Fv2osr5MJHvEOaL2qC4WXILCHUv3A6J9AUXpcQLA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Akira Yokosawa , Jonathan Corbet , Mauro Carvalho Chehab Subject: [PATCH 5.4 31/34] docs: submitting-patches: Fix crossref to The canonical patch format Date: Fri, 3 Jun 2022 19:43:27 +0200 Message-Id: <20220603173817.085758905@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173815.990072516@linuxfoundation.org> References: <20220603173815.990072516@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Akira Yokosawa commit 6d5aa418b3bd42cdccc36e94ee199af423ef7c84 upstream. The reference to `explicit_in_reply_to` is pointless as when the reference was added in the form of "#15" [1], Section 15) was "The canonical patch format". The reference of "#15" had not been properly updated in a couple of reorganizations during the plain-text SubmittingPatches era. Fix it by using `the_canonical_patch_format`. [1]: 2ae19acaa50a ("Documentation: Add "how to write a good patch summary" = to SubmittingPatches") Signed-off-by: Akira Yokosawa Fixes: 5903019b2a5e ("Documentation/SubmittingPatches: convert it to ReST m= arkup") Fixes: 9b2c76777acc ("Documentation/SubmittingPatches: enrich the Sphinx ou= tput") Cc: Jonathan Corbet Cc: Mauro Carvalho Chehab Cc: stable@vger.kernel.org # v4.9+ Link: https://lore.kernel.org/r/64e105a5-50be-23f2-6cae-903a2ea98e18@gmail.= com Signed-off-by: Jonathan Corbet Signed-off-by: Greg Kroah-Hartman Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee --- Documentation/process/submitting-patches.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/Documentation/process/submitting-patches.rst +++ b/Documentation/process/submitting-patches.rst @@ -133,7 +133,7 @@ as you intend it to. =20 The maintainer will thank you if you write your patch description in a form which can be easily pulled into Linux's source code management -system, ``git``, as a "commit log". See :ref:`explicit_in_reply_to`. +system, ``git``, as a "commit log". See :ref:`the_canonical_patch_format`. =20 Solve only one problem per patch. If your description starts to get long, that's a sign that you probably need to split up your patch. From nobody Tue Apr 28 06:24:51 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9558DC43334 for ; Fri, 3 Jun 2022 17:52:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345404AbiFCRw3 (ORCPT ); Fri, 3 Jun 2022 13:52:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46606 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345389AbiFCRsu (ORCPT ); Fri, 3 Jun 2022 13:48:50 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1E046C0C; Fri, 3 Jun 2022 10:45:34 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 5737360A52; Fri, 3 Jun 2022 17:45:33 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 55C42C385A9; Fri, 3 Jun 2022 17:45:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278332; bh=sfPesHts5NEETGJlacjo7cJ3lGQkFq0c+AHqqGjnCjA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=NLNF20dP4bXydS6BTyLjBsdNZQFccNjr1XpZecKmXNhAoYlULmx8xUKAuVfPAEq7d O6cAlign9KW5lYcusRKH0zU1Lgd4PWRF1Yn99TVcknDPne5V8aXxNqO/90k4QwG2se WCeguCXFiNM43aLCaLrCbaj/UpPVulbrvX77Do7g= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Olga Kornievskaia , Trond Myklebust , Anna Schumaker Subject: [PATCH 5.4 32/34] NFS: Memory allocation failures are not server fatal errors Date: Fri, 3 Jun 2022 19:43:28 +0200 Message-Id: <20220603173817.114480083@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173815.990072516@linuxfoundation.org> References: <20220603173815.990072516@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Trond Myklebust commit 452284407c18d8a522c3039339b1860afa0025a8 upstream. We need to filter out ENOMEM in nfs_error_is_fatal_on_server(), because running out of memory on our client is not a server error. Reported-by: Olga Kornievskaia Fixes: 2dc23afffbca ("NFS: ENOMEM should also be a fatal error.") Cc: stable@vger.kernel.org Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee --- fs/nfs/internal.h | 1 + 1 file changed, 1 insertion(+) --- a/fs/nfs/internal.h +++ b/fs/nfs/internal.h @@ -775,6 +775,7 @@ static inline bool nfs_error_is_fatal_on case 0: case -ERESTARTSYS: case -EINTR: + case -ENOMEM: return false; } return nfs_error_is_fatal(err); From nobody Tue Apr 28 06:24:51 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E313FCCA47C for ; Fri, 3 Jun 2022 17:52:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345419AbiFCRwh (ORCPT ); Fri, 3 Jun 2022 13:52:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43610 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345391AbiFCRsu (ORCPT ); Fri, 3 Jun 2022 13:48:50 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0203F55227; Fri, 3 Jun 2022 10:45:36 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 4E2D2604EF; Fri, 3 Jun 2022 17:45:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 58B36C385B8; Fri, 3 Jun 2022 17:45:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278335; bh=aRK5mDGZGC7naJL9YgFD6E9gV4OjjB5dfajnjI3ZvRI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Vlo3XtAAp+dVXHhYeMtJ+cZpvl+6gaPUa8RQT3T6MfXbfPxZuWSKhd8ZZeSFZ8lpk Mr9zerOzA5Rt74VDGKJ1AH4VK5QeZ/7/QGiM68rvwnXAHzt7xyPw/ZZY0bVWTYmdJj B93mmNaGTfdHNXgers2ogJRb5aIGiTeFJQX4sndo= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Dai Ngo , Chuck Lever Subject: [PATCH 5.4 33/34] NFSD: Fix possible sleep during nfsd4_release_lockowner() Date: Fri, 3 Jun 2022 19:43:29 +0200 Message-Id: <20220603173817.144471150@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173815.990072516@linuxfoundation.org> References: <20220603173815.990072516@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Chuck Lever commit ce3c4ad7f4ce5db7b4f08a1e237d8dd94b39180b upstream. nfsd4_release_lockowner() holds clp->cl_lock when it calls check_for_locks(). However, check_for_locks() calls nfsd_file_get() / nfsd_file_put() to access the backing inode's flc_posix list, and nfsd_file_put() can sleep if the inode was recently removed. Let's instead rely on the stateowner's reference count to gate whether the release is permitted. This should be a reliable indication of locks-in-use since file lock operations and ->lm_get_owner take appropriate references, which are released appropriately when file locks are removed. Reported-by: Dai Ngo Signed-off-by: Chuck Lever Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee --- fs/nfsd/nfs4state.c | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) --- a/fs/nfsd/nfs4state.c +++ b/fs/nfsd/nfs4state.c @@ -6894,16 +6894,12 @@ nfsd4_release_lockowner(struct svc_rqst if (sop->so_is_open_owner || !same_owner_str(sop, owner)) continue; =20 - /* see if there are still any locks associated with it */ - lo =3D lockowner(sop); - list_for_each_entry(stp, &sop->so_stateids, st_perstateowner) { - if (check_for_locks(stp->st_stid.sc_file, lo)) { - status =3D nfserr_locks_held; - spin_unlock(&clp->cl_lock); - return status; - } + if (atomic_read(&sop->so_count) !=3D 1) { + spin_unlock(&clp->cl_lock); + return nfserr_locks_held; } =20 + lo =3D lockowner(sop); nfs4_get_stateowner(sop); break; } From nobody Tue Apr 28 06:24:51 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3C435C43334 for ; Fri, 3 Jun 2022 17:52:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345478AbiFCRwr (ORCPT ); Fri, 3 Jun 2022 13:52:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44940 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345380AbiFCRsz (ORCPT ); Fri, 3 Jun 2022 13:48:55 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6289E55362; Fri, 3 Jun 2022 10:45:41 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id C7BA1B82436; Fri, 3 Jun 2022 17:45:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3761AC385A9; Fri, 3 Jun 2022 17:45:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278338; bh=dxjPZPVlqmjaq3Wp1+URqSoSvR4DtFcgfltGCSWzzCg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=tRapyWrZRZZIrB3oVG4BtVJXKHuMfoBFIeEDoH9alxYUNcp6Wdf8zJQrk0fc8CRY3 EysxVMrh1zMw3inBcqS3zrspx6Yv7/UBRgbGmDVDAlEDcUvYa/DEN6mQVYlOjw/kX6 6eF+CUfAJ59t81/zaR7MDZnVSTbBy/H56tWal0Ig= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Liu Jian , Daniel Borkmann , Song Liu Subject: [PATCH 5.4 34/34] bpf: Enlarge offset check value to INT_MAX in bpf_skb_{load,store}_bytes Date: Fri, 3 Jun 2022 19:43:30 +0200 Message-Id: <20220603173817.172203017@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173815.990072516@linuxfoundation.org> References: <20220603173815.990072516@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Liu Jian commit 45969b4152c1752089351cd6836a42a566d49bcf upstream. The data length of skb frags + frag_list may be greater than 0xffff, and skb_header_pointer can not handle negative offset. So, here INT_MAX is used to check the validity of offset. Add the same change to the related function skb_store_bytes. Fixes: 05c74e5e53f6 ("bpf: add bpf_skb_load_bytes helper") Signed-off-by: Liu Jian Signed-off-by: Daniel Borkmann Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20220416105801.88708-2-liujian56@huawei.c= om Signed-off-by: Greg Kroah-Hartman Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee --- net/core/filter.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/net/core/filter.c +++ b/net/core/filter.c @@ -1668,7 +1668,7 @@ BPF_CALL_5(bpf_skb_store_bytes, struct s =20 if (unlikely(flags & ~(BPF_F_RECOMPUTE_CSUM | BPF_F_INVALIDATE_HASH))) return -EINVAL; - if (unlikely(offset > 0xffff)) + if (unlikely(offset > INT_MAX)) return -EFAULT; if (unlikely(bpf_try_make_writable(skb, offset + len))) return -EFAULT; @@ -1703,7 +1703,7 @@ BPF_CALL_4(bpf_skb_load_bytes, const str { void *ptr; =20 - if (unlikely(offset > 0xffff)) + if (unlikely(offset > INT_MAX)) goto err_clear; =20 ptr =3D skb_header_pointer(skb, offset, len, to);