From nobody Sat May 2 09:01:00 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 12FCECCA473 for ; Fri, 3 Jun 2022 17:57:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345862AbiFCR5e (ORCPT ); Fri, 3 Jun 2022 13:57:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58234 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346598AbiFCRvT (ORCPT ); Fri, 3 Jun 2022 13:51:19 -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 1851153A65; Fri, 3 Jun 2022 10:48:50 -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 85AFD60F3E; Fri, 3 Jun 2022 17:48:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 863FBC341C0; Fri, 3 Jun 2022 17:48:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278529; bh=6Cm8N7iGoLf4zRP7xWJkH3JlP5PHe89qcww/m1kqHZs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=McYZb4N2/b1HzDu20A5iztWCVMDqgiXGNo2NRmfkbX1Q9zB68SKjrLuQH7EK2WKTx 6Zo8YHEy6gGd9TbJupZhAgfIf+vOPjOlye5THhgqmC0DNV7dAlnwPiyyknF2Fw55Jc 3UdwQANuCgKXxs4OPE5YkS0u4E/wKDoHXZIxe+FM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Forest Crossman , Takashi Iwai , Sasha Levin Subject: [PATCH 5.15 01/66] ALSA: usb-audio: Dont get sample rate for MCT Trigger 5 USB-to-HDMI Date: Fri, 3 Jun 2022 19:42:41 +0200 Message-Id: <20220603173820.709252634@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Forest Crossman [ Upstream commit d7be213849232a2accb219d537edf056d29186b4 ] This device doesn't support reading the sample rate, so we need to apply this quirk to avoid a 15-second delay waiting for three timeouts. Signed-off-by: Forest Crossman Link: https://lore.kernel.org/r/20220504002444.114011-2-cyrozap@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin Tested-by: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Sudip Mukherjee --- sound/usb/quirks.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/usb/quirks.c b/sound/usb/quirks.c index ab9f3da49941..fbbe59054c3f 100644 --- a/sound/usb/quirks.c +++ b/sound/usb/quirks.c @@ -1822,6 +1822,8 @@ static const struct usb_audio_quirk_flags_table quirk= _flags_table[] =3D { QUIRK_FLAG_IGNORE_CTL_ERROR), DEVICE_FLG(0x06f8, 0xd002, /* Hercules DJ Console (Macintosh Edition) */ QUIRK_FLAG_IGNORE_CTL_ERROR), + DEVICE_FLG(0x0711, 0x5800, /* MCT Trigger 5 USB-to-HDMI */ + QUIRK_FLAG_GET_SAMPLE_RATE), DEVICE_FLG(0x074d, 0x3553, /* Outlaw RR2150 (Micronas UAC3553B) */ QUIRK_FLAG_GET_SAMPLE_RATE), DEVICE_FLG(0x08bb, 0x2702, /* LineX FM Transmitter */ --=20 2.35.1 From nobody Sat May 2 09:01:00 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 A88EAC433EF for ; Fri, 3 Jun 2022 17:58:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345968AbiFCR6I (ORCPT ); Fri, 3 Jun 2022 13:58:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58274 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346752AbiFCRv3 (ORCPT ); Fri, 3 Jun 2022 13:51:29 -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 1D4705798D; Fri, 3 Jun 2022 10:49:23 -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 474A560F3E; Fri, 3 Jun 2022 17:49:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 412DDC385B8; Fri, 3 Jun 2022 17:49:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278562; bh=+8/rSL0dktqyZfvWABToCYxgk0Wct5z+yxpZFfy6gak=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=FwhH0zzWRRDj3Bp1eo7IjrJT7KDRKDZ6+JkhSzoGszROzvnC8S85aGiPeTOKxonjJ RH9BGimiM04iZxu0tzjZ/ircNtxg8AD/7IV2FT8UztY/hHwiBw9/IP4+IcSjAz7agH CpvHcJXYWgqR4FQsz4OtK/oz3YPkY4cv5DsPZ0QY= 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.15 02/66] pinctrl: sunxi: fix f1c100s uart2 function Date: Fri, 3 Jun 2022 19:42:42 +0200 Message-Id: <20220603173820.738267020@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos 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 Sat May 2 09:01:00 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 D5E9DC43334 for ; Fri, 3 Jun 2022 17:58:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346078AbiFCR6q (ORCPT ); Fri, 3 Jun 2022 13:58:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58222 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347038AbiFCRvv (ORCPT ); Fri, 3 Jun 2022 13:51:51 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9FEAB554AA; Fri, 3 Jun 2022 10:49:59 -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 16EF2B82189; Fri, 3 Jun 2022 17:49:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 43D7BC385A9; Fri, 3 Jun 2022 17:49:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278596; bh=cBNge5pbPFNpjc3yYWweALItim0uRV+wmebu8g7bA2c=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BxfzQk0DjF6l982A3cFNjv59cYTco406zLUmJhOSySZvURPiPZMrheuHe8Nczl8sJ Dhi/L/edIFQRBzQPVedCsG6ya9XGcMkURQwoeo5Bu5fUB6BJiWbinpITDKL9FHRWTS vbRPnVcKozPSIERR+aNO7NlmUI20WcQ8fFIl5OaM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Will Deacon , Quentin Perret , Marc Zyngier , Sasha Levin Subject: [PATCH 5.15 03/66] KVM: arm64: Dont hypercall before EL2 init Date: Fri, 3 Jun 2022 19:42:43 +0200 Message-Id: <20220603173820.766976339@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Quentin Perret [ Upstream commit 2e40316753ee552fb598e8da8ca0d20a04e67453 ] Will reported the following splat when running with Protected KVM enabled: [ 2.427181] ------------[ cut here ]------------ [ 2.427668] WARNING: CPU: 3 PID: 1 at arch/arm64/kvm/mmu.c:489 __create_= hyp_private_mapping+0x118/0x1ac [ 2.428424] Modules linked in: [ 2.429040] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 5.18.0-rc2-00084-g= 8635adc4efc7 #1 [ 2.429589] Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2= 015 [ 2.430286] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE= =3D--) [ 2.430734] pc : __create_hyp_private_mapping+0x118/0x1ac [ 2.431091] lr : create_hyp_exec_mappings+0x40/0x80 [ 2.431377] sp : ffff80000803baf0 [ 2.431597] x29: ffff80000803bb00 x28: 0000000000000000 x27: 00000000000= 00000 [ 2.432156] x26: 0000000000000000 x25: 0000000000000000 x24: 00000000000= 00000 [ 2.432561] x23: ffffcd96c343b000 x22: 0000000000000000 x21: ffff8000080= 3bb40 [ 2.433004] x20: 0000000000000004 x19: 0000000000001800 x18: 00000000000= 00000 [ 2.433343] x17: 0003e68cf7efdd70 x16: 0000000000000004 x15: fffffc81f60= 2a2c8 [ 2.434053] x14: ffffdf8380000000 x13: ffffcd9573200000 x12: ffffcd96c34= 3b000 [ 2.434401] x11: 0000000000000004 x10: ffffcd96c1738000 x9 : 00000000000= 00004 [ 2.434812] x8 : ffff80000803bb40 x7 : 7f7f7f7f7f7f7f7f x6 : 544f422efff= f306b [ 2.435136] x5 : 000000008020001e x4 : ffff207d80a88c00 x3 : 00000000000= 00005 [ 2.435480] x2 : 0000000000001800 x1 : 000000014f4ab800 x0 : 000000000ba= dca11 [ 2.436149] Call trace: [ 2.436600] __create_hyp_private_mapping+0x118/0x1ac [ 2.437576] create_hyp_exec_mappings+0x40/0x80 [ 2.438180] kvm_init_vector_slots+0x180/0x194 [ 2.458941] kvm_arch_init+0x80/0x274 [ 2.459220] kvm_init+0x48/0x354 [ 2.459416] arm_init+0x20/0x2c [ 2.459601] do_one_initcall+0xbc/0x238 [ 2.459809] do_initcall_level+0x94/0xb4 [ 2.460043] do_initcalls+0x54/0x94 [ 2.460228] do_basic_setup+0x1c/0x28 [ 2.460407] kernel_init_freeable+0x110/0x178 [ 2.460610] kernel_init+0x20/0x1a0 [ 2.460817] ret_from_fork+0x10/0x20 [ 2.461274] ---[ end trace 0000000000000000 ]--- Indeed, the Protected KVM mode promotes __create_hyp_private_mapping() to a hypercall as EL1 no longer has access to the hypervisor's stage-1 page-table. However, the call from kvm_init_vector_slots() happens after pKVM has been initialized on the primary CPU, but before it has been initialized on secondaries. As such, if the KVM initcall procedure is migrated from one CPU to another in this window, the hypercall may end up running on a CPU for which EL2 has not been initialized. Fortunately, the pKVM hypervisor doesn't rely on the host to re-map the vectors in the private range, so the hypercall in question is in fact superfluous. Skip it when pKVM is enabled. Reported-by: Will Deacon Signed-off-by: Quentin Perret [maz: simplified the checks slightly] Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20220513092607.35233-1-qperret@google.com Signed-off-by: Sasha Levin Tested-by: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Sudip Mukherjee --- arch/arm64/kvm/arm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c index 0b2f684cd8ca..a30c036577a3 100644 --- a/arch/arm64/kvm/arm.c +++ b/arch/arm64/kvm/arm.c @@ -1458,7 +1458,8 @@ static int kvm_init_vector_slots(void) base =3D kern_hyp_va(kvm_ksym_ref(__bp_harden_hyp_vecs)); kvm_init_vector_slot(base, HYP_VECTOR_SPECTRE_DIRECT); =20 - if (kvm_system_needs_idmapped_vectors() && !has_vhe()) { + if (kvm_system_needs_idmapped_vectors() && + !is_protected_kvm_enabled()) { err =3D create_hyp_exec_mappings(__pa_symbol(__bp_harden_hyp_vecs), __BP_HARDEN_HYP_VECS_SZ, &base); if (err) --=20 2.35.1 From nobody Sat May 2 09:01:00 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 EEF62C43334 for ; Fri, 3 Jun 2022 17:58:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346029AbiFCR64 (ORCPT ); Fri, 3 Jun 2022 13:58:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58166 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347176AbiFCRwG (ORCPT ); Fri, 3 Jun 2022 13:52:06 -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 90AAB580E5; Fri, 3 Jun 2022 10:50:14 -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 22EBDB82433; Fri, 3 Jun 2022 17:50:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 52F8AC385A9; Fri, 3 Jun 2022 17:50:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278611; bh=003EFPVAWAtkcipXIjXUvRz6XdQ5O2kKi9sJjDH1Xkc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=u+euc7qb4kO6+d5rhIiWOKX8hskIem9ANEPGXo3i3LBBLCKvdu2B4368kCgam91oy aww8iAPuXl3CpWhKI0rB1idv69OLgIX5sDSfyePGYqfhOTRa2nfSjf3lCgOR7SmQvk nmiJliLhd0G9BIQthbRnHLtBumDrEnVTGjaXnk2s= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, syzbot+5b1e53987f858500ec00@syzkaller.appspotmail.com, Al Viro , Sasha Levin Subject: [PATCH 5.15 04/66] percpu_ref_init(): clean ->percpu_count_ref on failure Date: Fri, 3 Jun 2022 19:42:44 +0200 Message-Id: <20220603173820.795000062@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Al Viro [ Upstream commit a91714312eb16f9ecd1f7f8b3efe1380075f28d4 ] That way percpu_ref_exit() is safe after failing percpu_ref_init(). At least one user (cgroup_create()) had a double-free that way; there might be other similar bugs. Easier to fix in percpu_ref_init(), rather than playing whack-a-mole in sloppy users... Usual symptoms look like a messed refcounting in one of subsystems that use percpu allocations (might be percpu-refcount, might be something else). Having refcounts for two different objects share memory is Not Nice(tm)... Reported-by: syzbot+5b1e53987f858500ec00@syzkaller.appspotmail.com Signed-off-by: Al Viro Signed-off-by: Sasha Levin Tested-by: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Sudip Mukherjee --- lib/percpu-refcount.c | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/percpu-refcount.c b/lib/percpu-refcount.c index af9302141bcf..e5c5315da274 100644 --- a/lib/percpu-refcount.c +++ b/lib/percpu-refcount.c @@ -76,6 +76,7 @@ int percpu_ref_init(struct percpu_ref *ref, percpu_ref_fu= nc_t *release, data =3D kzalloc(sizeof(*ref->data), gfp); if (!data) { free_percpu((void __percpu *)ref->percpu_count_ptr); + ref->percpu_count_ptr =3D 0; return -ENOMEM; } =20 --=20 2.35.1 From nobody Sat May 2 09:01:00 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 8EBE3C43334 for ; Fri, 3 Jun 2022 18:00:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346454AbiFCSAT (ORCPT ); Fri, 3 Jun 2022 14:00:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58276 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347184AbiFCRwG (ORCPT ); Fri, 3 Jun 2022 13:52:06 -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 B2AA2580ED; Fri, 3 Jun 2022 10:50: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 dfw.source.kernel.org (Postfix) with ESMTPS id 4D11860EE9; Fri, 3 Jun 2022 17:50:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4B8F1C385A9; Fri, 3 Jun 2022 17:50:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278614; bh=KsUOLGTDYelQAHVm3ByM7FFacF11O4D+xvLcvKIQpWA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=gFfz4iDj7Pci1Hb0XOPqEuAX48SftYVUnw1EyGYyOQTBYnFcB6nwRnHidySRPOKY1 WCC11evIUqyBcYHXYY5BESejSgXDqOIZPumBmWr9zl5EPzsF7W5UaFSH3McXKJY8RR mN0d9t2kktqOWldDO8UfsDpTopoNFDIAboMuHeCA= 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.15 05/66] net: af_key: check encryption module availability consistency Date: Fri, 3 Jun 2022 19:42:45 +0200 Message-Id: <20220603173820.822430301@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos 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 92e9d75dba2f..339d95df19d3 100644 --- a/net/key/af_key.c +++ b/net/key/af_key.c @@ -2900,7 +2900,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); @@ -2918,7 +2918,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++) { @@ -2929,7 +2929,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 Sat May 2 09:01:00 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 538D0CCA480 for ; Fri, 3 Jun 2022 18:00:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346509AbiFCSAW (ORCPT ); Fri, 3 Jun 2022 14:00:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58268 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347199AbiFCRwG (ORCPT ); Fri, 3 Jun 2022 13:52:06 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 81421580FB; Fri, 3 Jun 2022 10:50: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 dfw.source.kernel.org (Postfix) with ESMTPS id 1E1E660F38; Fri, 3 Jun 2022 17:50:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 28A55C385A9; Fri, 3 Jun 2022 17:50:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278617; bh=jHyM+b8du+a0HmzbYBcvIzJ3XESf7qdxLXW4V9tafjk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=dv8C97drc2hx3SG2X8abSEg3MRSaksqd5Z1wVHc0l+ITD3ZVicez29FRydzIQTBJ/ bGgdKpPdl+z7+veJBcIr73jzsoDL9cFReOyLTagxa01Du8un3EGTSfueDHwygj7jwd uCjNGDXntTfynAtoRYAx6VfBoxxXIkWxXbv3SuQw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Lin Ma , "David S. Miller" , Sasha Levin Subject: [PATCH 5.15 06/66] nfc: pn533: Fix buggy cleanup order Date: Fri, 3 Jun 2022 19:42:46 +0200 Message-Id: <20220603173820.850495224@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Lin Ma [ Upstream commit b8cedb7093b2d1394cae9b86494cba4b62d3a30a ] When removing the pn533 device (i2c or USB), there is a logic error. The original code first cancels the worker (flush_delayed_work) and then destroys the workqueue (destroy_workqueue), leaving the timer the last one to be deleted (del_timer). This result in a possible race condition in a multi-core preempt-able kernel. That is, if the cleanup (pn53x_common_clean) is concurrently run with the timer handler (pn533_listen_mode_timer), the timer can queue the poll_work to the already destroyed workqueue, causing use-after-free. This patch reorder the cleanup: it uses the del_timer_sync to make sure the handler is finished before the routine will destroy the workqueue. Note that the timer cannot be activated by the worker again. static void pn533_wq_poll(struct work_struct *work) ... rc =3D pn533_send_poll_frame(dev); if (rc) return; if (cur_mod->len =3D=3D 0 && dev->poll_mod_count > 1) mod_timer(&dev->listen_timer, ...); That is, the mod_timer can be called only when pn533_send_poll_frame() returns no error, which is impossible because the device is detaching and the lower driver should return ENODEV code. Signed-off-by: Lin Ma Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Tested-by: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Sudip Mukherjee --- drivers/nfc/pn533/pn533.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/nfc/pn533/pn533.c b/drivers/nfc/pn533/pn533.c index d32aec0c334f..6dc0af63440f 100644 --- a/drivers/nfc/pn533/pn533.c +++ b/drivers/nfc/pn533/pn533.c @@ -2789,13 +2789,14 @@ void pn53x_common_clean(struct pn533 *priv) { struct pn533_cmd *cmd, *n; =20 + /* delete the timer before cleanup the worker */ + del_timer_sync(&priv->listen_timer); + flush_delayed_work(&priv->poll_work); destroy_workqueue(priv->wq); =20 skb_queue_purge(&priv->resp_q); =20 - del_timer(&priv->listen_timer); - list_for_each_entry_safe(cmd, n, &priv->cmd_queue, queue) { list_del(&cmd->queue); kfree(cmd); --=20 2.35.1 From nobody Sat May 2 09:01:00 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 413D1CCA481 for ; Fri, 3 Jun 2022 18:00:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346396AbiFCSAQ (ORCPT ); Fri, 3 Jun 2022 14:00:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57820 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347197AbiFCRwG (ORCPT ); Fri, 3 Jun 2022 13:52:06 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4C5E658380; Fri, 3 Jun 2022 10:50:21 -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 DCF3360A0F; Fri, 3 Jun 2022 17:50:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F05CCC385A9; Fri, 3 Jun 2022 17:50:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278620; bh=rhSReVfYA015Yqcr13AeznBlSDShTNdEP+EIElwOAPE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=wygI1G6kaSgCTpR/GGrpEznWnAbKY6KXGVwNqETx3kVKuCI4LH/EGZkVXjoJSn8Yb KH2qgaZ1PpztoRsPB3hgKtDVzakkJf6vHttrnEs+2WyZDzsAf4cSt6cgElm3uSxzhL SV9oplhNmgyoMvUT6IId0MlUx4CgPhs/npxlN2jw= 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.15 07/66] net: ftgmac100: Disable hardware checksum on AST2600 Date: Fri, 3 Jun 2022 19:42:47 +0200 Message-Id: <20220603173820.878999533@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos 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 e1df2dc810a2..0b833572205f 100644 --- a/drivers/net/ethernet/faraday/ftgmac100.c +++ b/drivers/net/ethernet/faraday/ftgmac100.c @@ -1910,6 +1910,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 Sat May 2 09:01:00 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 1D80BC433EF for ; Fri, 3 Jun 2022 18:01:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346443AbiFCSBu (ORCPT ); Fri, 3 Jun 2022 14:01:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58378 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347200AbiFCRwG (ORCPT ); Fri, 3 Jun 2022 13:52:06 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4514C58381; Fri, 3 Jun 2022 10:50: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 D15EF60EE9; Fri, 3 Jun 2022 17:50:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D1C12C385B8; Fri, 3 Jun 2022 17:50:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278623; bh=yOdRLf0u+MxednDA4kOxzZaL4Ws4fqMSR0OzLc5pqPE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=z8Pl6P3qSdX7KZISAjtzovqhLCk8YqYPPNILp/qzJf6PDryG3Eb3TXawQxZmhxlma IawkjbeWXGSW545RLVPgFOHWkzfi8MpcXA5siL24fdsmdwOwy7+yIq80V7EFnhEaeZ ma5G/p0W6AShhY2Leg1AJ2NSV/b1DWLSllugokIw= 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.15 08/66] i2c: ismt: Provide a DMA buffer for Interrupt Cause Logging Date: Fri, 3 Jun 2022 19:42:48 +0200 Message-Id: <20220603173820.906833130@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos 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 a6187cbec2c9..af2c240e064e 100644 --- a/drivers/i2c/busses/i2c-ismt.c +++ b/drivers/i2c/busses/i2c-ismt.c @@ -82,6 +82,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 */ @@ -175,6 +176,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 static const struct pci_device_id ismt_ids[] =3D { @@ -411,6 +414,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; @@ -708,6 +714,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 @@ -795,6 +803,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 Sat May 2 09:01:00 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 0C707C43334 for ; Fri, 3 Jun 2022 18:01:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346398AbiFCSBg (ORCPT ); Fri, 3 Jun 2022 14:01:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58352 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347221AbiFCRwI (ORCPT ); Fri, 3 Jun 2022 13:52:08 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6F187580DB; Fri, 3 Jun 2022 10:50: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 08DBC60A0F; Fri, 3 Jun 2022 17:50:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C8068C385A9; Fri, 3 Jun 2022 17:50:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278626; bh=UIvOGU9ezNqd/V+eh1/mLYA2MyU4xUyFduSUC7Zg0Ms=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ZZXld4oAunwq6rx9uTuWWhBfDDSJLsJ7FHEwF8l4YfUe4rMPtSapxzLnqlGMBe1Jf yT7wXLocq957D7z6r4OASjq9I+MdFW7FVS44R8LT1GJVqA7IOEZNSza1kfU3YetvZM 17KIJu4I6VZv6J/V4SToYUScKjNTYU/tNxv87w80= 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.15 09/66] drivers: i2c: thunderx: Allow driver to work with ACPI defined TWSI controllers Date: Fri, 3 Jun 2022 19:42:49 +0200 Message-Id: <20220603173820.934599215@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos 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 12c90aa0900e..a77cd86fe75e 100644 --- a/drivers/i2c/busses/i2c-thunderx-pcidrv.c +++ b/drivers/i2c/busses/i2c-thunderx-pcidrv.c @@ -213,6 +213,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 Sat May 2 09:01:00 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 AFF74CCA473 for ; Fri, 3 Jun 2022 18:07:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346699AbiFCSFG (ORCPT ); Fri, 3 Jun 2022 14:05:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58162 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346609AbiFCRvU (ORCPT ); Fri, 3 Jun 2022 13:51:20 -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 C765A53E07; Fri, 3 Jun 2022 10:48:54 -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 6AF9BB82433; Fri, 3 Jun 2022 17:48:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BC5E4C385A9; Fri, 3 Jun 2022 17:48:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278532; bh=HIPwxM3SG7OAggDsq+SZEhp1UA+7mDVc78vPygtLu9M=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=EMo1ffA+T/LDLtx34sNZxXjtLc5oQ8nOyPVYVxqYmQd9rtT1NQwG7HwEMPwxqempa nf3Tn0R8pt+vjeCjPBYpDByd0Y513RFYpUM8Ln6Bth+4TBf2hCPKI03pRZsRKoCMR5 93GK86NvT6WPJumv3Mq1ZVqxos51gZ+NHQTlG3/E= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Pablo Neira Ayuso , Aaron Adams Subject: [PATCH 5.15 10/66] netfilter: nf_tables: disallow non-stateful expression in sets earlier Date: Fri, 3 Jun 2022 19:42:50 +0200 Message-Id: <20220603173820.961939465@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Pablo Neira Ayuso commit 520778042ccca019f3ffa136dd0ca565c486cedd upstream. Since 3e135cd499bf ("netfilter: nft_dynset: dynamic stateful expression instantiation"), it is possible to attach stateful expressions to set elements. cd5125d8f518 ("netfilter: nf_tables: split set destruction in deactivate and destroy phase") introduces conditional destruction on the object to accomodate transaction semantics. nft_expr_init() calls expr->ops->init() first, then check for NFT_STATEFUL_EXPR, this stills allows to initialize a non-stateful lookup expressions which points to a set, which might lead to UAF since the set is not properly detached from the set->binding for this case. Anyway, this combination is non-sense from nf_tables perspective. This patch fixes this problem by checking for NFT_STATEFUL_EXPR before expr->ops->init() is called. The reporter provides a KASAN splat and a poc reproducer (similar to those autogenerated by syzbot to report use-after-free errors). It is unknown to me if they are using syzbot or if they use similar automated tool to locate the bug that they are reporting. For the record, this is the KASAN splat. [ 85.431824] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [ 85.432901] BUG: KASAN: use-after-free in nf_tables_bind_set+0x81b/0xa20 [ 85.433825] Write of size 8 at addr ffff8880286f0e98 by task poc/776 [ 85.434756] [ 85.434999] CPU: 1 PID: 776 Comm: poc Tainted: G W 5.18.0= + #2 [ 85.436023] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS = 1.14.0-2 04/01/2014 Fixes: 0b2d8a7b638b ("netfilter: nf_tables: add helper functions for expres= sion handling") Reported-and-tested-by: Aaron Adams Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Sudip Mukherjee --- net/netfilter/nf_tables_api.c | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) --- a/net/netfilter/nf_tables_api.c +++ b/net/netfilter/nf_tables_api.c @@ -2778,27 +2778,31 @@ static struct nft_expr *nft_expr_init(co =20 err =3D nf_tables_expr_parse(ctx, nla, &expr_info); if (err < 0) - goto err1; + goto err_expr_parse; + + err =3D -EOPNOTSUPP; + if (!(expr_info.ops->type->flags & NFT_EXPR_STATEFUL)) + goto err_expr_stateful; =20 err =3D -ENOMEM; expr =3D kzalloc(expr_info.ops->size, GFP_KERNEL); if (expr =3D=3D NULL) - goto err2; + goto err_expr_stateful; =20 err =3D nf_tables_newexpr(ctx, &expr_info, expr); if (err < 0) - goto err3; + goto err_expr_new; =20 return expr; -err3: +err_expr_new: kfree(expr); -err2: +err_expr_stateful: owner =3D expr_info.ops->type->owner; if (expr_info.ops->type->release_ops) expr_info.ops->type->release_ops(expr_info.ops); =20 module_put(owner); -err1: +err_expr_parse: return ERR_PTR(err); } =20 @@ -5318,9 +5322,6 @@ struct nft_expr *nft_set_elem_expr_alloc return expr; =20 err =3D -EOPNOTSUPP; - if (!(expr->ops->type->flags & NFT_EXPR_STATEFUL)) - goto err_set_elem_expr; - if (expr->ops->type->flags & NFT_EXPR_GC) { if (set->flags & NFT_SET_TIMEOUT) goto err_set_elem_expr; From nobody Sat May 2 09:01:00 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 91304C43334 for ; Fri, 3 Jun 2022 18:07:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346439AbiFCSFD (ORCPT ); Fri, 3 Jun 2022 14:05:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58256 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346615AbiFCRvV (ORCPT ); Fri, 3 Jun 2022 13:51:21 -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 C014854187; Fri, 3 Jun 2022 10:48: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 76E14B82433; Fri, 3 Jun 2022 17:48:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CC3CAC36AF6; Fri, 3 Jun 2022 17:48:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278535; bh=K6tYsH8bSgs3PfSjUaakxOh0TLf3zeJAhtERYiKfyYg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ORzm4QPYXjNNyfGSqxgckTXm89Rhwbm5oBsW30YuSQGHVdrLhnbYcDDnS6cXfrfZv Q0O/kbuycwOMUXxXsXzqnVSGHcrStWZ88thQDfF2Gt098XlNvH1unu7yyNWtbkGlyN BS+92xLC7t6J4osP6eXZOtmmAgvvKlNBgnLDOETU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Dan Carpenter , Mika Westerberg , Linus Torvalds , Zheyu Ma Subject: [PATCH 5.15 11/66] i2c: ismt: prevent memory corruption in ismt_access() Date: Fri, 3 Jun 2022 19:42:51 +0200 Message-Id: <20220603173820.990767042@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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 690b2549b19563ec5ad53e5c82f6a944d910086e upstream. The "data->block[0]" variable comes from the user and is a number between 0-255. It needs to be capped to prevent writing beyond the end of dma_buffer[]. Fixes: 5e9a97b1f449 ("i2c: ismt: Adding support for I2C_SMBUS_BLOCK_PROC_CA= LL") Reported-and-tested-by: Zheyu Ma Signed-off-by: Dan Carpenter Reviewed-by: Mika Westerberg Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Sudip Mukherjee --- drivers/i2c/busses/i2c-ismt.c | 3 +++ 1 file changed, 3 insertions(+) --- a/drivers/i2c/busses/i2c-ismt.c +++ b/drivers/i2c/busses/i2c-ismt.c @@ -528,6 +528,9 @@ static int ismt_access(struct i2c_adapte =20 case I2C_SMBUS_BLOCK_PROC_CALL: dev_dbg(dev, "I2C_SMBUS_BLOCK_PROC_CALL\n"); + if (data->block[0] > I2C_SMBUS_BLOCK_MAX) + return -EINVAL; + dma_size =3D I2C_SMBUS_BLOCK_MAX; desc->tgtaddr_rw =3D ISMT_DESC_ADDR_RW(addr, 1); desc->wr_len_cmd =3D data->block[0] + 1; From nobody Sat May 2 09:01:00 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 3A868C433EF for ; Fri, 3 Jun 2022 18:07:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242855AbiFCSE6 (ORCPT ); Fri, 3 Jun 2022 14:04:58 -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 S1346642AbiFCRvY (ORCPT ); Fri, 3 Jun 2022 13:51:24 -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 ED6A15419E; Fri, 3 Jun 2022 10:49: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 A6052B82189; Fri, 3 Jun 2022 17:48:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1CD23C385B8; Fri, 3 Jun 2022 17:48:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278538; bh=ZCDvb/lEcXJjYOpYuWAGBXcbz47R0k27Spe8HvZyXr4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=pjUw+6h05kePkwTNEoFya0mh9sdxTIghyED6nOd/3U+F8b/qX3rZecscVJ/dWZmfI XdL+DwsFZGew6G5wmAAJnfLFWfDrpnvcO/1X2PQh/mp4802Am8gRiQq0nXjADy9Vr+ gmHy5+ycpFlE1nEU/QFi2iTDsDG8+L4GEkkiWOGQ= 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.15 12/66] assoc_array: Fix BUG_ON during garbage collect Date: Fri, 3 Jun 2022 19:42:52 +0200 Message-Id: <20220603173821.018593536@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos 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 Sat May 2 09:01:00 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 1DBB7C43334 for ; Fri, 3 Jun 2022 17:57:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345879AbiFCR5i (ORCPT ); Fri, 3 Jun 2022 13:57:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58106 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346665AbiFCRvZ (ORCPT ); Fri, 3 Jun 2022 13:51:25 -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 4A8515418F; Fri, 3 Jun 2022 10:49:04 -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 CFAF9B8241E; Fri, 3 Jun 2022 17:49:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 28899C385A9; Fri, 3 Jun 2022 17:49:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278541; bh=Lsl4MGIj+lFgH3ZgJ+tEmOVp6Tpf+jsCIrpUeJnyOnc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=pVaUuKpeLNRf41/hnxvQ0i/KTsc2GlfT6bWKOQs59Iip7cfR0nLPlBEgYME/5jb/F D2/H3HoeXdJQITk4IkqvXOiwoV40S6/UWc2WVYs0Vv74AbkJgKYuAki6MlVvNkq4hA faMHqE2dlwkK1OulGbQd5+kfwG7xBg5IyGAXLaq4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Kuniyuki Iwashima , Alexander Duyck , Al Viro , Davidlohr Bueso , Kuniyuki Iwashima , "Soheil Hassas Yeganeh" , "Sridhar Samudrala" , Andrew Morton Subject: [PATCH 5.15 13/66] pipe: make poll_usage boolean and annotate its access Date: Fri, 3 Jun 2022 19:42:53 +0200 Message-Id: <20220603173821.046674861@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Kuniyuki Iwashima commit f485922d8fe4e44f6d52a5bb95a603b7c65554bb upstream. Patch series "Fix data-races around epoll reported by KCSAN." This series suppresses a false positive KCSAN's message and fixes a real data-race. This patch (of 2): pipe_poll() runs locklessly and assigns 1 to poll_usage. Once poll_usage is set to 1, it never changes in other places. However, concurrent writes of a value trigger KCSAN, so let's make KCSAN happy. BUG: KCSAN: data-race in pipe_poll / pipe_poll write to 0xffff8880042f6678 of 4 bytes by task 174 on cpu 3: pipe_poll (fs/pipe.c:656) ep_item_poll.isra.0 (./include/linux/poll.h:88 fs/eventpoll.c:853) do_epoll_wait (fs/eventpoll.c:1692 fs/eventpoll.c:1806 fs/eventpoll.c:2234) __x64_sys_epoll_wait (fs/eventpoll.c:2246 fs/eventpoll.c:2241 fs/eventpoll= .c:2241) do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:113) write to 0xffff8880042f6678 of 4 bytes by task 177 on cpu 1: pipe_poll (fs/pipe.c:656) ep_item_poll.isra.0 (./include/linux/poll.h:88 fs/eventpoll.c:853) do_epoll_wait (fs/eventpoll.c:1692 fs/eventpoll.c:1806 fs/eventpoll.c:2234) __x64_sys_epoll_wait (fs/eventpoll.c:2246 fs/eventpoll.c:2241 fs/eventpoll= .c:2241) do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:113) Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 177 Comm: epoll_race Not tainted 5.17.0-58927-gf443e374ae13 #6 Hardware name: Red Hat KVM, BIOS 1.11.0-2.amzn2 04/01/2014 Link: https://lkml.kernel.org/r/20220322002653.33865-1-kuniyu@amazon.co.jp Link: https://lkml.kernel.org/r/20220322002653.33865-2-kuniyu@amazon.co.jp Fixes: 3b844826b6c6 ("pipe: avoid unnecessary EPOLLET wakeups under normal = loads") Signed-off-by: Kuniyuki Iwashima Cc: Alexander Duyck Cc: Al Viro Cc: Davidlohr Bueso Cc: Kuniyuki Iwashima Cc: "Soheil Hassas Yeganeh" Cc: "Sridhar Samudrala" Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Sudip Mukherjee --- fs/pipe.c | 2 +- include/linux/pipe_fs_i.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) --- a/fs/pipe.c +++ b/fs/pipe.c @@ -652,7 +652,7 @@ pipe_poll(struct file *filp, poll_table unsigned int head, tail; =20 /* Epoll has some historical nasty semantics, this enables them */ - pipe->poll_usage =3D 1; + WRITE_ONCE(pipe->poll_usage, true); =20 /* * Reading pipe state only -- no need for acquiring the semaphore. --- a/include/linux/pipe_fs_i.h +++ b/include/linux/pipe_fs_i.h @@ -71,7 +71,7 @@ struct pipe_inode_info { unsigned int files; unsigned int r_counter; unsigned int w_counter; - unsigned int poll_usage; + bool poll_usage; struct page *tmp_page; struct fasync_struct *fasync_readers; struct fasync_struct *fasync_writers; From nobody Sat May 2 09:01:00 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 A6CCEC433EF for ; Fri, 3 Jun 2022 17:57:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345805AbiFCR5m (ORCPT ); Fri, 3 Jun 2022 13:57:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46610 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346664AbiFCRvZ (ORCPT ); Fri, 3 Jun 2022 13:51:25 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 98810544C7; Fri, 3 Jun 2022 10:49: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 338F660F3B; Fri, 3 Jun 2022 17:49:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 37334C385A9; Fri, 3 Jun 2022 17:49:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278544; bh=QdzVgy+7LC1eSGiAnX9qGElIAQugWzv77O5yVZ37v+c=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=bJFUVTLa98eKqQC+bPkhR67o8+fzgiEWKXOn5ue1f9QmMnRA9wP3SZddZNnfP2vfT bNE2MeCZrGRtbMwA3tU/Gx2QWtwxnKK1ak0mxizOchniJpBHrVRLbFc6nwGUL8/26Y BP7kRX/KKnU4hQ62siIFK1XRYAfDxZc1NoOspdCo= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, David Howells , Linus Torvalds , zdi-disclosures@trendmicro.com Subject: [PATCH 5.15 14/66] pipe: Fix missing lock in pipe_resize_ring() Date: Fri, 3 Jun 2022 19:42:54 +0200 Message-Id: <20220603173821.075314499@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: David Howells commit 189b0ddc245139af81198d1a3637cac74f96e13a upstream. pipe_resize_ring() needs to take the pipe->rd_wait.lock spinlock to prevent post_one_notification() from trying to insert into the ring whilst the ring is being replaced. The occupancy check must be done after the lock is taken, and the lock must be taken after the new ring is allocated. The bug can lead to an oops looking something like: BUG: KASAN: use-after-free in post_one_notification.isra.0+0x62e/0x840 Read of size 4 at addr ffff88801cc72a70 by task poc/27196 ... Call Trace: post_one_notification.isra.0+0x62e/0x840 __post_watch_notification+0x3b7/0x650 key_create_or_update+0xb8b/0xd20 __do_sys_add_key+0x175/0x340 __x64_sys_add_key+0xbe/0x140 do_syscall_64+0x5c/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae Reported by Selim Enes Karaduman @Enesdex working with Trend Micro Zero Day Initiative. Fixes: c73be61cede5 ("pipe: Add general notification queue support") Reported-by: zdi-disclosures@trendmicro.com # ZDI-CAN-17291 Signed-off-by: David Howells Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Sudip Mukherjee --- fs/pipe.c | 31 ++++++++++++++++++------------- 1 file changed, 18 insertions(+), 13 deletions(-) --- a/fs/pipe.c +++ b/fs/pipe.c @@ -1244,30 +1244,33 @@ unsigned int round_pipe_size(unsigned lo =20 /* * Resize the pipe ring to a number of slots. + * + * Note the pipe can be reduced in capacity, but only if the current + * occupancy doesn't exceed nr_slots; if it does, EBUSY will be + * returned instead. */ int pipe_resize_ring(struct pipe_inode_info *pipe, unsigned int nr_slots) { struct pipe_buffer *bufs; unsigned int head, tail, mask, n; =20 - /* - * We can shrink the pipe, if arg is greater than the ring occupancy. - * Since we don't expect a lot of shrink+grow operations, just free and - * allocate again like we would do for growing. If the pipe currently - * contains more buffers than arg, then return busy. - */ - mask =3D pipe->ring_size - 1; - head =3D pipe->head; - tail =3D pipe->tail; - n =3D pipe_occupancy(pipe->head, pipe->tail); - if (nr_slots < n) - return -EBUSY; - bufs =3D kcalloc(nr_slots, sizeof(*bufs), GFP_KERNEL_ACCOUNT | __GFP_NOWARN); if (unlikely(!bufs)) return -ENOMEM; =20 + spin_lock_irq(&pipe->rd_wait.lock); + mask =3D pipe->ring_size - 1; + head =3D pipe->head; + tail =3D pipe->tail; + + n =3D pipe_occupancy(head, tail); + if (nr_slots < n) { + spin_unlock_irq(&pipe->rd_wait.lock); + kfree(bufs); + return -EBUSY; + } + /* * The pipe array wraps around, so just start the new one at zero * and adjust the indices. @@ -1299,6 +1302,8 @@ int pipe_resize_ring(struct pipe_inode_i pipe->tail =3D tail; pipe->head =3D head; =20 + spin_unlock_irq(&pipe->rd_wait.lock); + /* This might have made more room for writers */ wake_up_interruptible(&pipe->wr_wait); return 0; From nobody Sat May 2 09:01:00 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 1B0BCC43334 for ; Fri, 3 Jun 2022 17:57:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243330AbiFCR5v (ORCPT ); Fri, 3 Jun 2022 13:57:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46608 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346678AbiFCRv0 (ORCPT ); Fri, 3 Jun 2022 13:51:26 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BBE9C57142; Fri, 3 Jun 2022 10:49:08 -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 3276760F3E; Fri, 3 Jun 2022 17:49:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 415FEC385A9; Fri, 3 Jun 2022 17:49:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278547; bh=utL4tx2DU7lDNCDqgGRF69/Bgz6BQ0QQnq+uQiKu+Ts=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=wnD8Ug9TBwCV2MpRomjiBKJfzEo5rCVe+o8Qa+IuAKamgrCtA7rZIa+4rG7Fs4XNC hiT4xmM0gj1OemoFoz0NPFF1zw6XiY8BKhzW2IqjxGN3CYoUD+Gs3rdijhZyXxcUAP yTzeX4+tWQgZnlrPVXi/9mG2v2qbMiujfXxCRNqs= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Alex Elder , "David S. Miller" Subject: [PATCH 5.15 15/66] net: ipa: compute proper aggregation limit Date: Fri, 3 Jun 2022 19:42:55 +0200 Message-Id: <20220603173821.104884211@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Alex Elder commit c5794097b269f15961ed78f7f27b50e51766dec9 upstream. The aggregation byte limit for an endpoint is currently computed based on the endpoint's receive buffer size. However, some bytes at the front of each receive buffer are reserved on the assumption that--as with SKBs--it might be useful to insert data (such as headers) before what lands in the buffer. The aggregation byte limit currently doesn't take into account that reserved space, and as a result, aggregation could require space past that which is available in the buffer. Fix this by reducing the size used to compute the aggregation byte limit by the NET_SKB_PAD offset reserved for each receive buffer. Signed-off-by: Alex Elder Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Sudip Mukherjee --- drivers/net/ipa/ipa_endpoint.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/drivers/net/ipa/ipa_endpoint.c +++ b/drivers/net/ipa/ipa_endpoint.c @@ -722,13 +722,15 @@ static void ipa_endpoint_init_aggr(struc =20 if (endpoint->data->aggregation) { if (!endpoint->toward_ipa) { + u32 buffer_size; bool close_eof; u32 limit; =20 val |=3D u32_encode_bits(IPA_ENABLE_AGGR, AGGR_EN_FMASK); val |=3D u32_encode_bits(IPA_GENERIC, AGGR_TYPE_FMASK); =20 - limit =3D ipa_aggr_size_kb(IPA_RX_BUFFER_SIZE); + buffer_size =3D IPA_RX_BUFFER_SIZE - NET_SKB_PAD; + limit =3D ipa_aggr_size_kb(buffer_size); val |=3D aggr_byte_limit_encoded(version, limit); =20 limit =3D IPA_AGGR_TIME_LIMIT; From nobody Sat May 2 09:01:00 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 7281BCCA489 for ; Fri, 3 Jun 2022 18:00:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346262AbiFCSAI (ORCPT ); Fri, 3 Jun 2022 14:00:08 -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 S1346691AbiFCRv1 (ORCPT ); Fri, 3 Jun 2022 13:51:27 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ABF3E57157; Fri, 3 Jun 2022 10:49:11 -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 2D76E60F84; Fri, 3 Jun 2022 17:49:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3D63CC385A9; Fri, 3 Jun 2022 17:49:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278550; bh=DMacl7IqcY9xhZ6LfYAKsMrAmHpww3Czq1nsjIJ4w0g=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=QrxZztDQ/l4P6j3vBQ4Hn/G9ArFOz8dZ7vJwu1rqNAaAbPXOpkriNFIywQsAZFVLH ps75ECE+7jrki1FHtaUIg5majGpTvV8sLwQ06Q5vGxDYqYgXojFX1WHnqJHR9Gu82F x6O3dUaO9xNp7/vMh8C5nY+b49pKcrbJyoh/FZTg= 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.15 16/66] drm/i915: Fix -Wstringop-overflow warning in call to intel_read_wm_latency() Date: Fri, 3 Jun 2022 19:42:56 +0200 Message-Id: <20220603173821.132147840@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos 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 @@ -2863,7 +2863,7 @@ static void ilk_compute_wm_level(const s } =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 Sat May 2 09:01:00 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 22FBDC43334 for ; Fri, 3 Jun 2022 17:58:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241065AbiFCR54 (ORCPT ); Fri, 3 Jun 2022 13:57:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58038 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346700AbiFCRv1 (ORCPT ); Fri, 3 Jun 2022 13:51:27 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BB834544D9; Fri, 3 Jun 2022 10:49:14 -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 4AB8160F4E; Fri, 3 Jun 2022 17:49:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4B3FBC385A9; Fri, 3 Jun 2022 17:49:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278553; bh=ANH8V7vwcVhdW15W3pPGiL3w0hAGuSIPd+qqSu0L72w=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ZT2XqWWlNekzawtn7nLvsfJNuUvTJmKKK2PZbO0ekadarmzIqWma7xh3Xngr3kXY8 +ulyFicBtC4Mu6DXkvJWgBAKG0UZsrK4F4LDPIhQxgRK7LHowRf8NPKwY41nJmDpKm uLtFq3EaBGkctYFNH2UChFWQtknuVI7SMe2k7jas= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, syzbot+a4087e40b9c13aad7892@syzkaller.appspotmail.com, Tadeusz Struk , Sungjong Seo , Namjae Jeon Subject: [PATCH 5.15 17/66] exfat: check if cluster num is valid Date: Fri, 3 Jun 2022 19:42:57 +0200 Message-Id: <20220603173821.160226274@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Tadeusz Struk commit 64ba4b15e5c045f8b746c6da5fc9be9a6b00b61d upstream. Syzbot reported slab-out-of-bounds read in exfat_clear_bitmap. This was triggered by reproducer calling truncute with size 0, which causes the following trace: BUG: KASAN: slab-out-of-bounds in exfat_clear_bitmap+0x147/0x490 fs/exfat/b= alloc.c:174 Read of size 8 at addr ffff888115aa9508 by task syz-executor251/365 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack_lvl+0x1e2/0x24b lib/dump_stack.c:118 print_address_description+0x81/0x3c0 mm/kasan/report.c:233 __kasan_report mm/kasan/report.c:419 [inline] kasan_report+0x1a4/0x1f0 mm/kasan/report.c:436 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report_generic.c:309 exfat_clear_bitmap+0x147/0x490 fs/exfat/balloc.c:174 exfat_free_cluster+0x25a/0x4a0 fs/exfat/fatent.c:181 __exfat_truncate+0x99e/0xe00 fs/exfat/file.c:217 exfat_truncate+0x11b/0x4f0 fs/exfat/file.c:243 exfat_setattr+0xa03/0xd40 fs/exfat/file.c:339 notify_change+0xb76/0xe10 fs/attr.c:336 do_truncate+0x1ea/0x2d0 fs/open.c:65 Move the is_valid_cluster() helper from fatent.c to a common header to make it reusable in other *.c files. And add is_valid_cluster() to validate if cluster number is within valid range in exfat_clear_bitmap() and exfat_set_bitmap(). Link: https://syzkaller.appspot.com/bug?id=3D50381fc73821ecae743b8cf24b4c9a= 04776f767c Reported-by: syzbot+a4087e40b9c13aad7892@syzkaller.appspotmail.com Fixes: 1e49a94cf707 ("exfat: add bitmap operations") Cc: stable@vger.kernel.org # v5.7+ Signed-off-by: Tadeusz Struk Reviewed-by: Sungjong Seo Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Sudip Mukherjee --- fs/exfat/balloc.c | 8 ++++++-- fs/exfat/exfat_fs.h | 8 ++++++++ fs/exfat/fatent.c | 8 -------- 3 files changed, 14 insertions(+), 10 deletions(-) --- a/fs/exfat/balloc.c +++ b/fs/exfat/balloc.c @@ -148,7 +148,9 @@ int exfat_set_bitmap(struct inode *inode struct super_block *sb =3D inode->i_sb; struct exfat_sb_info *sbi =3D EXFAT_SB(sb); =20 - WARN_ON(clu < EXFAT_FIRST_CLUSTER); + if (!is_valid_cluster(sbi, clu)) + return -EINVAL; + ent_idx =3D CLUSTER_TO_BITMAP_ENT(clu); i =3D BITMAP_OFFSET_SECTOR_INDEX(sb, ent_idx); b =3D BITMAP_OFFSET_BIT_IN_SECTOR(sb, ent_idx); @@ -166,7 +168,9 @@ void exfat_clear_bitmap(struct inode *in struct exfat_sb_info *sbi =3D EXFAT_SB(sb); struct exfat_mount_options *opts =3D &sbi->options; =20 - WARN_ON(clu < EXFAT_FIRST_CLUSTER); + if (!is_valid_cluster(sbi, clu)) + return; + ent_idx =3D CLUSTER_TO_BITMAP_ENT(clu); i =3D BITMAP_OFFSET_SECTOR_INDEX(sb, ent_idx); b =3D BITMAP_OFFSET_BIT_IN_SECTOR(sb, ent_idx); --- a/fs/exfat/exfat_fs.h +++ b/fs/exfat/exfat_fs.h @@ -381,6 +381,14 @@ static inline int exfat_sector_to_cluste EXFAT_RESERVED_CLUSTERS; } =20 +static inline bool is_valid_cluster(struct exfat_sb_info *sbi, + unsigned int clus) +{ + if (clus < EXFAT_FIRST_CLUSTER || sbi->num_clusters <=3D clus) + return false; + return true; +} + /* super.c */ int exfat_set_volume_dirty(struct super_block *sb); int exfat_clear_volume_dirty(struct super_block *sb); --- a/fs/exfat/fatent.c +++ b/fs/exfat/fatent.c @@ -81,14 +81,6 @@ int exfat_ent_set(struct super_block *sb return 0; } =20 -static inline bool is_valid_cluster(struct exfat_sb_info *sbi, - unsigned int clus) -{ - if (clus < EXFAT_FIRST_CLUSTER || sbi->num_clusters <=3D clus) - return false; - return true; -} - int exfat_ent_get(struct super_block *sb, unsigned int loc, unsigned int *content) { From nobody Sat May 2 09:01:00 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 D8180CCA47C for ; Fri, 3 Jun 2022 18:00:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346229AbiFCSAB (ORCPT ); Fri, 3 Jun 2022 14:00:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58298 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346709AbiFCRv1 (ORCPT ); Fri, 3 Jun 2022 13:51:27 -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 35D7954686; Fri, 3 Jun 2022 10:49: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 dfw.source.kernel.org (Postfix) with ESMTPS id 625D760EE9; Fri, 3 Jun 2022 17:49:17 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5021EC3411D; Fri, 3 Jun 2022 17:49:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278556; bh=GBMWw5YIL4CtdnTTC7cdooXOb1zCbcApFTrIwNej5P0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=r/k1x0G/h/nyRvYdlzUadzPG5EeGDxE3mea+gckrQnVwDZD/N3Bv/7Dtn3ftOwAQp IsH2jviXGqvwyNUg/lIp5Eipr/XnhGMtKxF2D+WU+miQpQsvmENoplNMsF8SG0YRKx PxpuK+n1WJzXXGJ9d9/esOot/pRnGH93ktMXkywE= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Yuezhang Mo , Andy Wu , Aoyama Wataru , Daniel Palmer , Sungjong Seo , Namjae Jeon Subject: [PATCH 5.15 18/66] exfat: fix referencing wrong parent directory information after renaming Date: Fri, 3 Jun 2022 19:42:58 +0200 Message-Id: <20220603173821.189285919@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Yuezhang Mo commit d8dad2588addd1d861ce19e7df3b702330f0c7e3 upstream. During renaming, the parent directory information maybe updated. But the file/directory still references to the old parent directory information. This bug will cause 2 problems. (1) The renamed file can not be written. [10768.175172] exFAT-fs (sda1): error, failed to bmap (inode : 7afd50e4= iblock : 0, err : -5) [10768.184285] exFAT-fs (sda1): Filesystem has been set read-only ash: write error: Input/output error (2) Some dentries of the renamed file/directory are not set to deleted after removing the file/directory. exfat_update_parent_info() is a workaround for the wrong parent directory information being used after renaming. Now that bug is fixed, this is no longer needed, so remove it. Fixes: 5f2aa075070c ("exfat: add inode operations") Cc: stable@vger.kernel.org # v5.7+ Signed-off-by: Yuezhang Mo Reviewed-by: Andy Wu Reviewed-by: Aoyama Wataru Reviewed-by: Daniel Palmer Reviewed-by: Sungjong Seo Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Sudip Mukherjee --- fs/exfat/namei.c | 27 +-------------------------- 1 file changed, 1 insertion(+), 26 deletions(-) --- a/fs/exfat/namei.c +++ b/fs/exfat/namei.c @@ -1069,6 +1069,7 @@ static int exfat_rename_file(struct inod =20 exfat_remove_entries(inode, p_dir, oldentry, 0, num_old_entries); + ei->dir =3D *p_dir; ei->entry =3D newentry; } else { if (exfat_get_entry_type(epold) =3D=3D TYPE_FILE) { @@ -1159,28 +1160,6 @@ static int exfat_move_file(struct inode return 0; } =20 -static void exfat_update_parent_info(struct exfat_inode_info *ei, - struct inode *parent_inode) -{ - struct exfat_sb_info *sbi =3D EXFAT_SB(parent_inode->i_sb); - struct exfat_inode_info *parent_ei =3D EXFAT_I(parent_inode); - loff_t parent_isize =3D i_size_read(parent_inode); - - /* - * the problem that struct exfat_inode_info caches wrong parent info. - * - * because of flag-mismatch of ei->dir, - * there is abnormal traversing cluster chain. - */ - if (unlikely(parent_ei->flags !=3D ei->dir.flags || - parent_isize !=3D EXFAT_CLU_TO_B(ei->dir.size, sbi) || - parent_ei->start_clu !=3D ei->dir.dir)) { - exfat_chain_set(&ei->dir, parent_ei->start_clu, - EXFAT_B_TO_CLU_ROUND_UP(parent_isize, sbi), - parent_ei->flags); - } -} - /* rename or move a old file into a new file */ static int __exfat_rename(struct inode *old_parent_inode, struct exfat_inode_info *ei, struct inode *new_parent_inode, @@ -1211,8 +1190,6 @@ static int __exfat_rename(struct inode * return -ENOENT; } =20 - exfat_update_parent_info(ei, old_parent_inode); - exfat_chain_dup(&olddir, &ei->dir); dentry =3D ei->entry; =20 @@ -1233,8 +1210,6 @@ static int __exfat_rename(struct inode * goto out; } =20 - exfat_update_parent_info(new_ei, new_parent_inode); - p_dir =3D &(new_ei->dir); new_entry =3D new_ei->entry; ep =3D exfat_get_dentry(sb, p_dir, new_entry, &new_bh, NULL); From nobody Sat May 2 09:01:00 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 F1073CCA473 for ; Fri, 3 Jun 2022 17:58:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345950AbiFCR6E (ORCPT ); Fri, 3 Jun 2022 13:58:04 -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 S1346751AbiFCRv3 (ORCPT ); Fri, 3 Jun 2022 13:51:29 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 68A635715E; Fri, 3 Jun 2022 10:49: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 ams.source.kernel.org (Postfix) with ESMTPS id CDE78B8241D; Fri, 3 Jun 2022 17:49:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 319C1C385A9; Fri, 3 Jun 2022 17:49:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278559; bh=ygwq7yfFRXP9bKkF4D16aTkBxZUxyK/GL3hNi2M+PPk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=VmxlhS1U+0k0mMK0G9bMr8K4jxCwBUpokRALtNDv+6jmJrU0OTZSfPR4Cjl4Q2oai 6JVcqbpQk2nxSSmH5gH3WSGdlZKrFih5IQdJQxcgugDxcJAfUZ+d4tyK9wnUn8DLCe gfY8WoUb77yLbxUptG07y5k0qbGZlgFwnFPNEMFk= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Herbert Xu , linux-crypto@vger.kernel.org, "Justin M. Forbes" , "Jason A. Donenfeld" Subject: [PATCH 5.15 19/66] lib/crypto: add prompts back to crypto libraries Date: Fri, 3 Jun 2022 19:42:59 +0200 Message-Id: <20220603173821.218500114@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: "Justin M. Forbes" commit e56e18985596617ae426ed5997fb2e737cffb58b upstream. Commit 6048fdcc5f269 ("lib/crypto: blake2s: include as built-in") took away a number of prompt texts from other crypto libraries. This makes values flip from built-in to module when oldconfig runs, and causes problems when these crypto libs need to be built in for thingslike BIG_KEYS. Fixes: 6048fdcc5f269 ("lib/crypto: blake2s: include as built-in") Cc: Herbert Xu Cc: linux-crypto@vger.kernel.org Signed-off-by: Justin M. Forbes [Jason: - moved menu into submenu of lib/ instead of root menu - fixed chacha sub-dependencies for CONFIG_CRYPTO] Signed-off-by: Jason A. Donenfeld Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Sudip Mukherjee --- crypto/Kconfig | 2 -- lib/Kconfig | 2 ++ lib/crypto/Kconfig | 17 ++++++++++++----- 3 files changed, 14 insertions(+), 7 deletions(-) --- a/crypto/Kconfig +++ b/crypto/Kconfig @@ -1924,5 +1924,3 @@ source "crypto/asymmetric_keys/Kconfig" source "certs/Kconfig" =20 endif # if CRYPTO - -source "lib/crypto/Kconfig" --- a/lib/Kconfig +++ b/lib/Kconfig @@ -121,6 +121,8 @@ config INDIRECT_IOMEM_FALLBACK mmio accesses when the IO memory address is not a registered emulated region. =20 +source "lib/crypto/Kconfig" + config CRC_CCITT tristate "CRC-CCITT functions" help --- a/lib/crypto/Kconfig +++ b/lib/crypto/Kconfig @@ -1,5 +1,7 @@ # SPDX-License-Identifier: GPL-2.0 =20 +menu "Crypto library routines" + config CRYPTO_LIB_AES tristate =20 @@ -31,7 +33,7 @@ config CRYPTO_ARCH_HAVE_LIB_CHACHA =20 config CRYPTO_LIB_CHACHA_GENERIC tristate - select CRYPTO_ALGAPI + select XOR_BLOCKS help This symbol can be depended upon by arch implementations of the ChaCha library interface that require the generic code as a @@ -40,7 +42,8 @@ config CRYPTO_LIB_CHACHA_GENERIC of CRYPTO_LIB_CHACHA. =20 config CRYPTO_LIB_CHACHA - tristate + tristate "ChaCha library interface" + depends on CRYPTO depends on CRYPTO_ARCH_HAVE_LIB_CHACHA || !CRYPTO_ARCH_HAVE_LIB_CHACHA select CRYPTO_LIB_CHACHA_GENERIC if CRYPTO_ARCH_HAVE_LIB_CHACHA=3Dn help @@ -65,7 +68,7 @@ config CRYPTO_LIB_CURVE25519_GENERIC of CRYPTO_LIB_CURVE25519. =20 config CRYPTO_LIB_CURVE25519 - tristate + tristate "Curve25519 scalar multiplication library" depends on CRYPTO_ARCH_HAVE_LIB_CURVE25519 || !CRYPTO_ARCH_HAVE_LIB_CURVE= 25519 select CRYPTO_LIB_CURVE25519_GENERIC if CRYPTO_ARCH_HAVE_LIB_CURVE25519= =3Dn help @@ -100,7 +103,7 @@ config CRYPTO_LIB_POLY1305_GENERIC of CRYPTO_LIB_POLY1305. =20 config CRYPTO_LIB_POLY1305 - tristate + tristate "Poly1305 library interface" depends on CRYPTO_ARCH_HAVE_LIB_POLY1305 || !CRYPTO_ARCH_HAVE_LIB_POLY1305 select CRYPTO_LIB_POLY1305_GENERIC if CRYPTO_ARCH_HAVE_LIB_POLY1305=3Dn help @@ -109,14 +112,18 @@ config CRYPTO_LIB_POLY1305 is available and enabled. =20 config CRYPTO_LIB_CHACHA20POLY1305 - tristate + tristate "ChaCha20-Poly1305 AEAD support (8-byte nonce library version)" depends on CRYPTO_ARCH_HAVE_LIB_CHACHA || !CRYPTO_ARCH_HAVE_LIB_CHACHA depends on CRYPTO_ARCH_HAVE_LIB_POLY1305 || !CRYPTO_ARCH_HAVE_LIB_POLY1305 + depends on CRYPTO select CRYPTO_LIB_CHACHA select CRYPTO_LIB_POLY1305 + select CRYPTO_ALGAPI =20 config CRYPTO_LIB_SHA256 tristate =20 config CRYPTO_LIB_SM4 tristate + +endmenu From nobody Sat May 2 09:01:00 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 2DCA3CCA47E for ; Fri, 3 Jun 2022 18:00:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346333AbiFCSAN (ORCPT ); Fri, 3 Jun 2022 14:00:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58230 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346815AbiFCRvc (ORCPT ); Fri, 3 Jun 2022 13:51:32 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 817F557B00; Fri, 3 Jun 2022 10:49:28 -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 E2391B82419; Fri, 3 Jun 2022 17:49:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 495DEC385B8; Fri, 3 Jun 2022 17:49:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278565; bh=TIS2GoTaI2/zpFafNEpWpq5sRvOtRLPlkLlhchtllhE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=E6Oz771+h058gH4BVniw3drqvTvpvd3Cw7vUhIXYqaEktyxq9BWzXCmVaiHaqSVdi NGQONY3J/ZB+oTG//wqJDHTgloX0hdYqY37Pag5gum479eNtAOArwYL/rysCfHFRlm VfiQ+vZL4pgGhiflW74opXMrYp3HJhmpbLfb5TOI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Nicolai Stange , =?UTF-8?q?Stephan=20M=C3=BCller?= , Herbert Xu , "Jason A. Donenfeld" Subject: [PATCH 5.15 20/66] crypto: drbg - prepare for more fine-grained tracking of seeding state Date: Fri, 3 Jun 2022 19:43:00 +0200 Message-Id: <20220603173821.247230562@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Nicolai Stange commit ce8ce31b2c5c8b18667784b8c515650c65d57b4e upstream. There are two different randomness sources the DRBGs are getting seeded from, namely the jitterentropy source (if enabled) and get_random_bytes(). At initial DRBG seeding time during boot, the latter might not have collected sufficient entropy for seeding itself yet and thus, the DRBG implementation schedules a reseed work from a random_ready_callback once that has happened. This is particularly important for the !->pr DRBG instances, for which (almost) no further reseeds are getting triggered during their lifetime. Because collecting data from the jitterentropy source is a rather expensive operation, the aforementioned asynchronously scheduled reseed work restricts itself to get_random_bytes() only. That is, it in some sense amends the initial DRBG seed derived from jitterentropy output at full (estimated) entropy with fresh randomness obtained from get_random_bytes() once that has been seeded with sufficient entropy itself. With the advent of rng_is_initialized(), there is no real need for doing the reseed operation from an asynchronously scheduled work anymore and a subsequent patch will make it synchronous by moving it next to related logic already present in drbg_generate(). However, for tracking whether a full reseed including the jitterentropy source is required or a "partial" reseed involving only get_random_bytes() would be sufficient already, the boolean struct drbg_state's ->seeded member must become a tristate value. Prepare for this by introducing the new enum drbg_seed_state and change struct drbg_state's ->seeded member's type from bool to that type. For facilitating review, enum drbg_seed_state is made to only contain two members corresponding to the former ->seeded values of false and true resp. at this point: DRBG_SEED_STATE_UNSEEDED and DRBG_SEED_STATE_FULL. A third one for tracking the intermediate state of "seeded from jitterentropy only" will be introduced with a subsequent patch. There is no change in behaviour at this point. Signed-off-by: Nicolai Stange Reviewed-by: Stephan M=C3=BCller Signed-off-by: Herbert Xu Signed-off-by: Jason A. Donenfeld Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Sudip Mukherjee --- crypto/drbg.c | 19 ++++++++++--------- include/crypto/drbg.h | 7 ++++++- 2 files changed, 16 insertions(+), 10 deletions(-) --- a/crypto/drbg.c +++ b/crypto/drbg.c @@ -1043,7 +1043,7 @@ static inline int __drbg_seed(struct drb if (ret) return ret; =20 - drbg->seeded =3D true; + drbg->seeded =3D DRBG_SEED_STATE_FULL; /* 10.1.1.2 / 10.1.1.3 step 5 */ drbg->reseed_ctr =3D 1; =20 @@ -1088,14 +1088,14 @@ static void drbg_async_seed(struct work_ if (ret) goto unlock; =20 - /* Set seeded to false so that if __drbg_seed fails the - * next generate call will trigger a reseed. + /* Reset ->seeded so that if __drbg_seed fails the next + * generate call will trigger a reseed. */ - drbg->seeded =3D false; + drbg->seeded =3D DRBG_SEED_STATE_UNSEEDED; =20 __drbg_seed(drbg, &seedlist, true); =20 - if (drbg->seeded) + if (drbg->seeded =3D=3D DRBG_SEED_STATE_FULL) drbg->reseed_threshold =3D drbg_max_requests(drbg); =20 unlock: @@ -1386,13 +1386,14 @@ static int drbg_generate(struct drbg_sta * here. The spec is a bit convoluted here, we make it simpler. */ if (drbg->reseed_threshold < drbg->reseed_ctr) - drbg->seeded =3D false; + drbg->seeded =3D DRBG_SEED_STATE_UNSEEDED; =20 - if (drbg->pr || !drbg->seeded) { + if (drbg->pr || drbg->seeded =3D=3D DRBG_SEED_STATE_UNSEEDED) { pr_devel("DRBG: reseeding before generation (prediction " "resistance: %s, state %s)\n", drbg->pr ? "true" : "false", - drbg->seeded ? "seeded" : "unseeded"); + (drbg->seeded =3D=3D DRBG_SEED_STATE_FULL ? + "seeded" : "unseeded")); /* 9.3.1 steps 7.1 through 7.3 */ len =3D drbg_seed(drbg, addtl, true); if (len) @@ -1577,7 +1578,7 @@ static int drbg_instantiate(struct drbg_ if (!drbg->core) { drbg->core =3D &drbg_cores[coreref]; drbg->pr =3D pr; - drbg->seeded =3D false; + drbg->seeded =3D DRBG_SEED_STATE_UNSEEDED; drbg->reseed_threshold =3D drbg_max_requests(drbg); =20 ret =3D drbg_alloc_state(drbg); --- a/include/crypto/drbg.h +++ b/include/crypto/drbg.h @@ -105,6 +105,11 @@ struct drbg_test_data { struct drbg_string *testentropy; /* TEST PARAMETER: test entropy */ }; =20 +enum drbg_seed_state { + DRBG_SEED_STATE_UNSEEDED, + DRBG_SEED_STATE_FULL, +}; + struct drbg_state { struct mutex drbg_mutex; /* lock around DRBG */ unsigned char *V; /* internal state 10.1.1.1 1a) */ @@ -127,7 +132,7 @@ struct drbg_state { struct crypto_wait ctr_wait; /* CTR mode async wait obj */ struct scatterlist sg_in, sg_out; /* CTR mode SGLs */ =20 - bool seeded; /* DRBG fully seeded? */ + enum drbg_seed_state seeded; /* DRBG fully seeded? */ bool pr; /* Prediction resistance enabled? */ bool fips_primed; /* Continuous test primed? */ unsigned char *prev; /* FIPS 140-2 continuous test value */ From nobody Sat May 2 09:01:00 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 A57E9C43334 for ; Fri, 3 Jun 2022 17:58:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345970AbiFCR6R (ORCPT ); Fri, 3 Jun 2022 13:58:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57862 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346851AbiFCRvd (ORCPT ); Fri, 3 Jun 2022 13:51:33 -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 ED7285A14E; Fri, 3 Jun 2022 10:49:31 -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 E8256B8241D; Fri, 3 Jun 2022 17:49:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5D5E6C385A9; Fri, 3 Jun 2022 17:49:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278568; bh=wMXW1oBXczTkWZkB6PBlZvnK8EWYustjA0G0yHzI99c=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GK1sqUbB0bkrFB7AVskfutpAd0YiHKlzEGgunCSAQvEiwZA6atmWL4dUbhW20n9Id 1Ci0ImlOYeMjEa8jrNQwOPQd1aDpb4O9E3D3GAitQgyqZ0g1rQqTKZXKZSoxMXX5BX tIHlXSNYX9X+zdQ9bfuM2oMdB+Ycnu9OKIY08p/w= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Nicolai Stange , =?UTF-8?q?Stephan=20M=C3=BCller?= , Herbert Xu , "Jason A. Donenfeld" Subject: [PATCH 5.15 21/66] crypto: drbg - track whether DRBG was seeded with !rng_is_initialized() Date: Fri, 3 Jun 2022 19:43:01 +0200 Message-Id: <20220603173821.274689389@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Nicolai Stange commit 2bcd25443868aa8863779a6ebc6c9319633025d2 upstream. Currently, the DRBG implementation schedules asynchronous works from random_ready_callbacks for reseeding the DRBG instances with output from get_random_bytes() once the latter has sufficient entropy available. However, as the get_random_bytes() initialization state can get queried by means of rng_is_initialized() now, there is no real need for this asynchronous reseeding logic anymore and it's better to keep things simple by doing it synchronously when needed instead, i.e. from drbg_generate() once rng_is_initialized() has flipped to true. Of course, for this to work, drbg_generate() would need some means by which it can tell whether or not rng_is_initialized() has flipped to true since the last seeding from get_random_bytes(). Or equivalently, whether or not the last seed from get_random_bytes() has happened when rng_is_initialized() was still evaluating to false. As it currently stands, enum drbg_seed_state allows for the representation of two different DRBG seeding states: DRBG_SEED_STATE_UNSEEDED and DRBG_SEED_STATE_FULL. The former makes drbg_generate() to invoke a full reseeding operation involving both, the rather expensive jitterentropy as well as the get_random_bytes() randomness sources. The DRBG_SEED_STATE_FULL state on the other hand implies that no reseeding at all is required for a !->pr DRBG variant. Introduce the new DRBG_SEED_STATE_PARTIAL state to enum drbg_seed_state for representing the condition that a DRBG was being seeded when rng_is_initialized() had still been false. In particular, this new state implies that - the given DRBG instance has been fully seeded from the jitterentropy source (if enabled) - and drbg_generate() is supposed to reseed from get_random_bytes() *only* once rng_is_initialized() turns to true. Up to now, the __drbg_seed() helper used to set the given DRBG instance's ->seeded state to constant DRBG_SEED_STATE_FULL. Introduce a new argument allowing for the specification of the to be written ->seeded value instead. Make the first of its two callers, drbg_seed(), determine the appropriate value based on rng_is_initialized(). The remaining caller, drbg_async_seed(), is known to get invoked only once rng_is_initialized() is true, hence let it pass constant DRBG_SEED_STATE_FULL for the new argument to __drbg_seed(). There is no change in behaviour, except for that the pr_devel() in drbg_generate() would now report "unseeded" for ->pr DRBG instances which had last been seeded when rng_is_initialized() was still evaluating to false. Signed-off-by: Nicolai Stange Reviewed-by: Stephan M=C3=BCller Signed-off-by: Herbert Xu Signed-off-by: Jason A. Donenfeld Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Sudip Mukherjee --- crypto/drbg.c | 12 ++++++++---- include/crypto/drbg.h | 1 + 2 files changed, 9 insertions(+), 4 deletions(-) --- a/crypto/drbg.c +++ b/crypto/drbg.c @@ -1036,14 +1036,14 @@ static const struct drbg_state_ops drbg_ ******************************************************************/ =20 static inline int __drbg_seed(struct drbg_state *drbg, struct list_head *s= eed, - int reseed) + int reseed, enum drbg_seed_state new_seed_state) { int ret =3D drbg->d_ops->update(drbg, seed, reseed); =20 if (ret) return ret; =20 - drbg->seeded =3D DRBG_SEED_STATE_FULL; + drbg->seeded =3D new_seed_state; /* 10.1.1.2 / 10.1.1.3 step 5 */ drbg->reseed_ctr =3D 1; =20 @@ -1093,7 +1093,7 @@ static void drbg_async_seed(struct work_ */ drbg->seeded =3D DRBG_SEED_STATE_UNSEEDED; =20 - __drbg_seed(drbg, &seedlist, true); + __drbg_seed(drbg, &seedlist, true, DRBG_SEED_STATE_FULL); =20 if (drbg->seeded =3D=3D DRBG_SEED_STATE_FULL) drbg->reseed_threshold =3D drbg_max_requests(drbg); @@ -1123,6 +1123,7 @@ static int drbg_seed(struct drbg_state * unsigned int entropylen =3D drbg_sec_strength(drbg->core->flags); struct drbg_string data1; LIST_HEAD(seedlist); + enum drbg_seed_state new_seed_state =3D DRBG_SEED_STATE_FULL; =20 /* 9.1 / 9.2 / 9.3.1 step 3 */ if (pers && pers->len > (drbg_max_addtl(drbg))) { @@ -1150,6 +1151,9 @@ static int drbg_seed(struct drbg_state * BUG_ON((entropylen * 2) > sizeof(entropy)); =20 /* Get seed from in-kernel /dev/urandom */ + if (!rng_is_initialized()) + new_seed_state =3D DRBG_SEED_STATE_PARTIAL; + ret =3D drbg_get_random_bytes(drbg, entropy, entropylen); if (ret) goto out; @@ -1206,7 +1210,7 @@ static int drbg_seed(struct drbg_state * memset(drbg->C, 0, drbg_statelen(drbg)); } =20 - ret =3D __drbg_seed(drbg, &seedlist, reseed); + ret =3D __drbg_seed(drbg, &seedlist, reseed, new_seed_state); =20 out: memzero_explicit(entropy, entropylen * 2); --- a/include/crypto/drbg.h +++ b/include/crypto/drbg.h @@ -107,6 +107,7 @@ struct drbg_test_data { =20 enum drbg_seed_state { DRBG_SEED_STATE_UNSEEDED, + DRBG_SEED_STATE_PARTIAL, /* Seeded with !rng_is_initialized() */ DRBG_SEED_STATE_FULL, }; =20 From nobody Sat May 2 09:01:00 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 5C370C433EF for ; Fri, 3 Jun 2022 17:58:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346050AbiFCR6N (ORCPT ); Fri, 3 Jun 2022 13:58:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46532 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346857AbiFCRvd (ORCPT ); Fri, 3 Jun 2022 13:51:33 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 46E975A156; Fri, 3 Jun 2022 10:49:33 -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 8F3E460F3E; Fri, 3 Jun 2022 17:49:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 77C8EC385A9; Fri, 3 Jun 2022 17:49:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278572; bh=mIDAvWxdB6qqu9n87Qx4+I7DdbEph4ufuQK535negPs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=m0Y+R7YoKbh5zV9B4gfQTwR1z8XcPhtDroeB1lrzctoLlDrVQE+8K5V2n6lMSHqv6 3OKFQk7TWPe36n8B0yFWxe6mp2rulbfPZ91J6ON3lVYSpQ87sgJi7Ns0Q74mEhka4a uohjK5K7sB3EpWZd+5G9jqEQ9Q9parREs4iWB3Jg= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Nicolai Stange , =?UTF-8?q?Stephan=20M=C3=BCller?= , Herbert Xu , "Jason A. Donenfeld" Subject: [PATCH 5.15 22/66] crypto: drbg - move dynamic ->reseed_threshold adjustments to __drbg_seed() Date: Fri, 3 Jun 2022 19:43:02 +0200 Message-Id: <20220603173821.302120799@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Nicolai Stange commit 262d83a4290c331cd4f617a457408bdb82fbb738 upstream. Since commit 42ea507fae1a ("crypto: drbg - reseed often if seedsource is degraded"), the maximum seed lifetime represented by ->reseed_threshold gets temporarily lowered if the get_random_bytes() source cannot provide sufficient entropy yet, as is common during boot, and restored back to the original value again once that has changed. More specifically, if the add_random_ready_callback() invoked from drbg_prepare_hrng() in the course of DRBG instantiation does not return -EALREADY, that is, if get_random_bytes() has not been fully initialized at this point yet, drbg_prepare_hrng() will lower ->reseed_threshold to a value of 50. The drbg_async_seed() scheduled from said random_ready_callback will eventually restore the original value. A future patch will replace the random_ready_callback based notification mechanism and thus, there will be no add_random_ready_callback() return value anymore which could get compared to -EALREADY. However, there's __drbg_seed() which gets invoked in the course of both, the DRBG instantiation as well as the eventual reseeding from get_random_bytes() in aforementioned drbg_async_seed(), if any. Moreover, it knows about the get_random_bytes() initialization state by the time the seed data had been obtained from it: the new_seed_state argument introduced with the previous patch would get set to DRBG_SEED_STATE_PARTIAL in case get_random_bytes() had not been fully initialized yet and to DRBG_SEED_STATE_FULL otherwise. Thus, __drbg_seed() provides a convenient alternative for managing that ->reseed_threshold lowering and restoring at a central place. Move all ->reseed_threshold adjustment code from drbg_prepare_hrng() and drbg_async_seed() respectively to __drbg_seed(). Make __drbg_seed() lower the ->reseed_threshold to 50 in case its new_seed_state argument equals DRBG_SEED_STATE_PARTIAL and let it restore the original value otherwise. There is no change in behaviour. Signed-off-by: Nicolai Stange Reviewed-by: Stephan M=C3=BCller Signed-off-by: Herbert Xu Signed-off-by: Jason A. Donenfeld Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Sudip Mukherjee --- crypto/drbg.c | 30 +++++++++++++++++++++--------- 1 file changed, 21 insertions(+), 9 deletions(-) --- a/crypto/drbg.c +++ b/crypto/drbg.c @@ -1047,6 +1047,27 @@ static inline int __drbg_seed(struct drb /* 10.1.1.2 / 10.1.1.3 step 5 */ drbg->reseed_ctr =3D 1; =20 + switch (drbg->seeded) { + case DRBG_SEED_STATE_UNSEEDED: + /* Impossible, but handle it to silence compiler warnings. */ + fallthrough; + case DRBG_SEED_STATE_PARTIAL: + /* + * Require frequent reseeds until the seed source is + * fully initialized. + */ + drbg->reseed_threshold =3D 50; + break; + + case DRBG_SEED_STATE_FULL: + /* + * Seed source has become fully initialized, frequent + * reseeds no longer required. + */ + drbg->reseed_threshold =3D drbg_max_requests(drbg); + break; + } + return ret; } =20 @@ -1095,9 +1116,6 @@ static void drbg_async_seed(struct work_ =20 __drbg_seed(drbg, &seedlist, true, DRBG_SEED_STATE_FULL); =20 - if (drbg->seeded =3D=3D DRBG_SEED_STATE_FULL) - drbg->reseed_threshold =3D drbg_max_requests(drbg); - unlock: mutex_unlock(&drbg->drbg_mutex); =20 @@ -1533,12 +1551,6 @@ static int drbg_prepare_hrng(struct drbg return err; } =20 - /* - * Require frequent reseeds until the seed source is fully - * initialized. - */ - drbg->reseed_threshold =3D 50; - return err; } =20 From nobody Sat May 2 09:01:00 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 28E01C433EF for ; Fri, 3 Jun 2022 18:04:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346613AbiFCSEt (ORCPT ); Fri, 3 Jun 2022 14:04:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58378 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346883AbiFCRvk (ORCPT ); Fri, 3 Jun 2022 13:51:40 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E05B75A177; Fri, 3 Jun 2022 10:49: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 ams.source.kernel.org (Postfix) with ESMTPS id 63D43B82419; Fri, 3 Jun 2022 17:49:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BDF10C385B8; Fri, 3 Jun 2022 17:49:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278575; bh=ipZcC2jtV5Q4Qj1Dp9l8yK4rjUTbEqlUrAnsKnOmn2w=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=cugaINUMe+RNfRHwbQ/4wE2H4MYC8HLs9cMBj1s+qc5nLBYnpGswrIVt21Ne3rOPm KdgvYUlNkZNRTEMqOf/Ak2KaNJ0gJ5pRQxWnMxD8VTSHuK3+EgAbagh26gNZAMhYBk 4IvpY1Q7ka4d2dGaQszrDYSqA/wKYLCrg7rOrDw4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Nicolai Stange , Herbert Xu , "Jason A. Donenfeld" Subject: [PATCH 5.15 23/66] crypto: drbg - make reseeding from get_random_bytes() synchronous Date: Fri, 3 Jun 2022 19:43:03 +0200 Message-Id: <20220603173821.330116342@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Nicolai Stange commit 074bcd4000e0d812bc253f86fedc40f81ed59ccc upstream. get_random_bytes() usually hasn't full entropy available by the time DRBG instances are first getting seeded from it during boot. Thus, the DRBG implementation registers random_ready_callbacks which would in turn schedule some work for reseeding the DRBGs once get_random_bytes() has sufficient entropy available. For reference, the relevant history around handling DRBG (re)seeding in the context of a not yet fully seeded get_random_bytes() is: commit 16b369a91d0d ("random: Blocking API for accessing nonblocking_pool") commit 4c7879907edd ("crypto: drbg - add async seeding operation") commit 205a525c3342 ("random: Add callback API for random pool readiness") commit 57225e679788 ("crypto: drbg - Use callback API for random readiness") commit c2719503f5e1 ("random: Remove kernel blocking API") However, some time later, the initialization state of get_random_bytes() has been made queryable via rng_is_initialized() introduced with commit 9a47249d444d ("random: Make crng state queryable"). This primitive now allows for streamlining the DRBG reseeding from get_random_bytes() by replacing that aforementioned asynchronous work scheduling from random_ready_callbacks with some simpler, synchronous code in drbg_generate() next to the related logic already present therein. Apart from improving overall code readability, this change will also enable DRBG users to rely on wait_for_random_bytes() for ensuring that the initial seeding has completed, if desired. The previous patches already laid the grounds by making drbg_seed() to record at each DRBG instance whether it was being seeded at a time when rng_is_initialized() still had been false as indicated by ->seeded =3D=3D DRBG_SEED_STATE_PARTIAL. All that remains to be done now is to make drbg_generate() check for this condition, determine whether rng_is_initialized() has flipped to true in the meanwhile and invoke a reseed from get_random_bytes() if so. Make this move: - rename the former drbg_async_seed() work handler, i.e. the one in charge of reseeding a DRBG instance from get_random_bytes(), to "drbg_seed_from_random()", - change its signature as appropriate, i.e. make it take a struct drbg_state rather than a work_struct and change its return type from "void" to "int" in order to allow for passing error information from e.g. its __drbg_seed() invocation onwards to callers, - make drbg_generate() invoke this drbg_seed_from_random() once it encounters a DRBG instance with ->seeded =3D=3D DRBG_SEED_STATE_PARTIAL by the time rng_is_initialized() has flipped to true and - prune everything related to the former, random_ready_callback based mechanism. As drbg_seed_from_random() is now getting invoked from drbg_generate() with the ->drbg_mutex being held, it must not attempt to recursively grab it once again. Remove the corresponding mutex operations from what is now drbg_seed_from_random(). Furthermore, as drbg_seed_from_random() can now report errors directly to its caller, there's no need for it to temporarily switch the DRBG's ->seeded state to DRBG_SEED_STATE_UNSEEDED so that a failure of the subsequently invoked __drbg_seed() will get signaled to drbg_generate(). Don't do it then. Signed-off-by: Nicolai Stange Signed-off-by: Herbert Xu [Jason: for stable, undid the modifications for the backport of 5acd3548.] Signed-off-by: Jason A. Donenfeld Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Sudip Mukherjee --- crypto/drbg.c | 61 +++++++++------------------------------------= ----- drivers/char/random.c | 2 - include/crypto/drbg.h | 2 - 3 files changed, 11 insertions(+), 54 deletions(-) --- a/crypto/drbg.c +++ b/crypto/drbg.c @@ -1087,12 +1087,10 @@ static inline int drbg_get_random_bytes( return 0; } =20 -static void drbg_async_seed(struct work_struct *work) +static int drbg_seed_from_random(struct drbg_state *drbg) { struct drbg_string data; LIST_HEAD(seedlist); - struct drbg_state *drbg =3D container_of(work, struct drbg_state, - seed_work); unsigned int entropylen =3D drbg_sec_strength(drbg->core->flags); unsigned char entropy[32]; int ret; @@ -1103,23 +1101,15 @@ static void drbg_async_seed(struct work_ drbg_string_fill(&data, entropy, entropylen); list_add_tail(&data.list, &seedlist); =20 - mutex_lock(&drbg->drbg_mutex); - ret =3D drbg_get_random_bytes(drbg, entropy, entropylen); if (ret) - goto unlock; - - /* Reset ->seeded so that if __drbg_seed fails the next - * generate call will trigger a reseed. - */ - drbg->seeded =3D DRBG_SEED_STATE_UNSEEDED; + goto out; =20 - __drbg_seed(drbg, &seedlist, true, DRBG_SEED_STATE_FULL); - -unlock: - mutex_unlock(&drbg->drbg_mutex); + ret =3D __drbg_seed(drbg, &seedlist, true, DRBG_SEED_STATE_FULL); =20 +out: memzero_explicit(entropy, entropylen); + return ret; } =20 /* @@ -1422,6 +1412,11 @@ static int drbg_generate(struct drbg_sta goto err; /* 9.3.1 step 7.4 */ addtl =3D NULL; + } else if (rng_is_initialized() && + drbg->seeded =3D=3D DRBG_SEED_STATE_PARTIAL) { + len =3D drbg_seed_from_random(drbg); + if (len) + goto err; } =20 if (addtl && 0 < addtl->len) @@ -1514,44 +1509,15 @@ static int drbg_generate_long(struct drb return 0; } =20 -static int drbg_schedule_async_seed(struct notifier_block *nb, unsigned lo= ng action, void *data) -{ - struct drbg_state *drbg =3D container_of(nb, struct drbg_state, - random_ready); - - schedule_work(&drbg->seed_work); - return 0; -} - static int drbg_prepare_hrng(struct drbg_state *drbg) { - int err; - /* We do not need an HRNG in test mode. */ if (list_empty(&drbg->test_data.list)) return 0; =20 drbg->jent =3D crypto_alloc_rng("jitterentropy_rng", 0, 0); =20 - INIT_WORK(&drbg->seed_work, drbg_async_seed); - - drbg->random_ready.notifier_call =3D drbg_schedule_async_seed; - err =3D register_random_ready_notifier(&drbg->random_ready); - - switch (err) { - case 0: - break; - - case -EALREADY: - err =3D 0; - fallthrough; - - default: - drbg->random_ready.notifier_call =3D NULL; - return err; - } - - return err; + return 0; } =20 /* @@ -1645,11 +1611,6 @@ free_everything: */ static int drbg_uninstantiate(struct drbg_state *drbg) { - if (drbg->random_ready.notifier_call) { - unregister_random_ready_notifier(&drbg->random_ready); - cancel_work_sync(&drbg->seed_work); - } - if (!IS_ERR_OR_NULL(drbg->jent)) crypto_free_rng(drbg->jent); drbg->jent =3D NULL; --- a/drivers/char/random.c +++ b/drivers/char/random.c @@ -163,7 +163,6 @@ int __cold register_random_ready_notifie spin_unlock_irqrestore(&random_ready_chain_lock, flags); return ret; } -EXPORT_SYMBOL(register_random_ready_notifier); =20 /* * Delete a previously registered readiness callback function. @@ -178,7 +177,6 @@ int __cold unregister_random_ready_notif spin_unlock_irqrestore(&random_ready_chain_lock, flags); return ret; } -EXPORT_SYMBOL(unregister_random_ready_notifier); =20 static void __cold process_random_ready_list(void) { --- a/include/crypto/drbg.h +++ b/include/crypto/drbg.h @@ -137,12 +137,10 @@ struct drbg_state { bool pr; /* Prediction resistance enabled? */ bool fips_primed; /* Continuous test primed? */ unsigned char *prev; /* FIPS 140-2 continuous test value */ - struct work_struct seed_work; /* asynchronous seeding support */ struct crypto_rng *jent; const struct drbg_state_ops *d_ops; const struct drbg_core *core; struct drbg_string test_data; - struct notifier_block random_ready; }; =20 static inline __u8 drbg_statelen(struct drbg_state *drbg) From nobody Sat May 2 09:01:00 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 B72D6C433EF for ; Fri, 3 Jun 2022 18:04:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346601AbiFCSEq (ORCPT ); Fri, 3 Jun 2022 14:04:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58124 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346895AbiFCRvm (ORCPT ); Fri, 3 Jun 2022 13:51:42 -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 AA05F5A2C0; Fri, 3 Jun 2022 10:49:40 -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 60F2BB8241D; Fri, 3 Jun 2022 17:49:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BC04CC385A9; Fri, 3 Jun 2022 17:49:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278578; bh=3pOtbOQ8N6t6Rw8X0QXHDepYORdmz7gTCpQzOAuGKFw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Xm6i/q4Vejn9VTe96rfn4svdWLV1V2Wq/9LUWvyyPEa/UV+dIK571ZOwBbPePjNJU hK9EJQmNnJgSrU4BhTZXteY8Wpuj9y2FpbVE+Id/hdlal4q8HTSmgtJuTTqpIj7nId yVFKJJN/vyrlzNi2yFSP5sUYnNgNjQCZ9MFHN0oM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, zhangziming.zzm@antgroup.com, Stefano Brivio , Florian Westphal , Pablo Neira Ayuso Subject: [PATCH 5.15 24/66] netfilter: nf_tables: sanitize nft_set_desc_concat_parse() Date: Fri, 3 Jun 2022 19:43:04 +0200 Message-Id: <20220603173821.358045008@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Pablo Neira Ayuso commit fecf31ee395b0295f2d7260aa29946b7605f7c85 upstream. Add several sanity checks for nft_set_desc_concat_parse(): - validate desc->field_count not larger than desc->field_len array. - field length cannot be larger than desc->field_len (ie. U8_MAX) - total length of the concatenation cannot be larger than register array. Joint work with Florian Westphal. Fixes: f3a2181e16f1 ("netfilter: nf_tables: Support for sets with multiple = ranged fields") Reported-by: Reviewed-by: Stefano Brivio Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Sudip Mukherjee --- net/netfilter/nf_tables_api.c | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) --- a/net/netfilter/nf_tables_api.c +++ b/net/netfilter/nf_tables_api.c @@ -4151,6 +4151,9 @@ static int nft_set_desc_concat_parse(con u32 len; int err; =20 + if (desc->field_count >=3D ARRAY_SIZE(desc->field_len)) + return -E2BIG; + err =3D nla_parse_nested_deprecated(tb, NFTA_SET_FIELD_MAX, attr, nft_concat_policy, NULL); if (err < 0) @@ -4160,9 +4163,8 @@ static int nft_set_desc_concat_parse(con return -EINVAL; =20 len =3D ntohl(nla_get_be32(tb[NFTA_SET_FIELD_LEN])); - - if (len * BITS_PER_BYTE / 32 > NFT_REG32_COUNT) - return -E2BIG; + if (!len || len > U8_MAX) + return -EINVAL; =20 desc->field_len[desc->field_count++] =3D len; =20 @@ -4173,7 +4175,8 @@ static int nft_set_desc_concat(struct nf const struct nlattr *nla) { struct nlattr *attr; - int rem, err; + u32 num_regs =3D 0; + int rem, err, i; =20 nla_for_each_nested(attr, nla, rem) { if (nla_type(attr) !=3D NFTA_LIST_ELEM) @@ -4184,6 +4187,12 @@ static int nft_set_desc_concat(struct nf return err; } =20 + for (i =3D 0; i < desc->field_count; i++) + num_regs +=3D DIV_ROUND_UP(desc->field_len[i], sizeof(u32)); + + if (num_regs > NFT_REG32_COUNT) + return -E2BIG; + return 0; } From nobody Sat May 2 09:01:00 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 659BFC43334 for ; Fri, 3 Jun 2022 17:58:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244407AbiFCR6b (ORCPT ); Fri, 3 Jun 2022 13:58:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58150 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346910AbiFCRvn (ORCPT ); Fri, 3 Jun 2022 13:51:43 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EC63C5A2D3; Fri, 3 Jun 2022 10:49: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 78694B823B0; Fri, 3 Jun 2022 17:49:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C7596C385A9; Fri, 3 Jun 2022 17:49:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278581; bh=yIwoTYmHgD13KMGXjAlET+J3WJrNlVW7f/gtREit0J4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SvxysiI9hT6hxFhB3/+LKTcMFZbW/3N5IygwGDxCmTp4Jx/B46CU/yAUVrSxo2YYM s21U21GQAnM36Pa+yFuTtwbpp6/aXvjTccr4Jay1M5eXmCHQ1F/rXnz1WRw5oIme8D 54nj5TujdYG2O1ZXkqRiecdW9Ra9L5k8ockAqZn8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Pablo Neira Ayuso Subject: [PATCH 5.15 25/66] netfilter: nf_tables: hold mutex on netns pre_exit path Date: Fri, 3 Jun 2022 19:43:05 +0200 Message-Id: <20220603173821.385759263@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Pablo Neira Ayuso commit 3923b1e4406680d57da7e873da77b1683035d83f upstream. clean_net() runs in workqueue while walking over the lists, grab mutex. Fixes: 767d1216bff8 ("netfilter: nftables: fix possible UAF over chains fro= m packet path in netns") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Sudip Mukherjee --- net/netfilter/nf_tables_api.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/net/netfilter/nf_tables_api.c +++ b/net/netfilter/nf_tables_api.c @@ -9746,7 +9746,11 @@ static int __net_init nf_tables_init_net =20 static void __net_exit nf_tables_pre_exit_net(struct net *net) { + struct nftables_pernet *nft_net =3D nft_pernet(net); + + mutex_lock(&nft_net->commit_mutex); __nft_release_hooks(net); + mutex_unlock(&nft_net->commit_mutex); } =20 static void __net_exit nf_tables_exit_net(struct net *net) From nobody Sat May 2 09:01:00 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 DAB12C43334 for ; Fri, 3 Jun 2022 17:58:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345768AbiFCR60 (ORCPT ); Fri, 3 Jun 2022 13:58:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58234 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346922AbiFCRvo (ORCPT ); Fri, 3 Jun 2022 13:51:44 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A46085A2E3; Fri, 3 Jun 2022 10:49: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 0C5B160F70; Fri, 3 Jun 2022 17:49:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F1BE8C385B8; Fri, 3 Jun 2022 17:49:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278584; bh=OpaawRp79dtqnGSTyBaISZA/NROjTyAbG0fSnlPKS2A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=I5ycwedZrRL8BUDL5lng82Cqr/3Zmn3HXF8Wni1yq+wuHQAY/OuOpfHCGOD5vBCjE Bhs5WxvFGX+cbdJzCVw1+Ill+lMZdb8DxcEVAJWvwwdsPI4dwHx8tS2Up942QJYCBt Be+XJWWtjyqkslK0ComaVGmqYsTtljZdFOUj9PSI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Pablo Neira Ayuso Subject: [PATCH 5.15 26/66] netfilter: nf_tables: double hook unregistration in netns path Date: Fri, 3 Jun 2022 19:43:06 +0200 Message-Id: <20220603173821.413744948@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Pablo Neira Ayuso commit f9a43007d3f7ba76d5e7f9421094f00f2ef202f8 upstream. __nft_release_hooks() is called from pre_netns exit path which unregisters the hooks, then the NETDEV_UNREGISTER event is triggered which unregisters the hooks again. [ 565.221461] WARNING: CPU: 18 PID: 193 at net/netfilter/core.c:495 __nf_u= nregister_net_hook+0x247/0x270 [...] [ 565.246890] CPU: 18 PID: 193 Comm: kworker/u64:1 Tainted: G E= 5.18.0-rc7+ #27 [ 565.253682] Workqueue: netns cleanup_net [ 565.257059] RIP: 0010:__nf_unregister_net_hook+0x247/0x270 [...] [ 565.297120] Call Trace: [ 565.300900] [ 565.304683] nf_tables_flowtable_event+0x16a/0x220 [nf_tables] [ 565.308518] raw_notifier_call_chain+0x63/0x80 [ 565.312386] unregister_netdevice_many+0x54f/0xb50 Unregister and destroy netdev hook from netns pre_exit via kfree_rcu so the NETDEV_UNREGISTER path see unregistered hooks. Fixes: 767d1216bff8 ("netfilter: nftables: fix possible UAF over chains fro= m packet path in netns") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Sudip Mukherjee --- net/netfilter/nf_tables_api.c | 54 +++++++++++++++++++++++++++++++------= ----- 1 file changed, 41 insertions(+), 13 deletions(-) --- a/net/netfilter/nf_tables_api.c +++ b/net/netfilter/nf_tables_api.c @@ -222,12 +222,18 @@ err_register: } =20 static void nft_netdev_unregister_hooks(struct net *net, - struct list_head *hook_list) + struct list_head *hook_list, + bool release_netdev) { - struct nft_hook *hook; + struct nft_hook *hook, *next; =20 - list_for_each_entry(hook, hook_list, list) + list_for_each_entry_safe(hook, next, hook_list, list) { nf_unregister_net_hook(net, &hook->ops); + if (release_netdev) { + list_del(&hook->list); + kfree_rcu(hook, rcu); + } + } } =20 static int nf_tables_register_hook(struct net *net, @@ -253,9 +259,10 @@ static int nf_tables_register_hook(struc return nf_register_net_hook(net, &basechain->ops); } =20 -static void nf_tables_unregister_hook(struct net *net, - const struct nft_table *table, - struct nft_chain *chain) +static void __nf_tables_unregister_hook(struct net *net, + const struct nft_table *table, + struct nft_chain *chain, + bool release_netdev) { struct nft_base_chain *basechain; const struct nf_hook_ops *ops; @@ -270,11 +277,19 @@ static void nf_tables_unregister_hook(st return basechain->type->ops_unregister(net, ops); =20 if (nft_base_chain_netdev(table->family, basechain->ops.hooknum)) - nft_netdev_unregister_hooks(net, &basechain->hook_list); + nft_netdev_unregister_hooks(net, &basechain->hook_list, + release_netdev); else nf_unregister_net_hook(net, &basechain->ops); } =20 +static void nf_tables_unregister_hook(struct net *net, + const struct nft_table *table, + struct nft_chain *chain) +{ + return __nf_tables_unregister_hook(net, table, chain, false); +} + static void nft_trans_commit_list_add_tail(struct net *net, struct nft_tra= ns *trans) { struct nftables_pernet *nft_net =3D nft_pernet(net); @@ -7206,13 +7221,25 @@ static void nft_unregister_flowtable_hoo FLOW_BLOCK_UNBIND); } =20 -static void nft_unregister_flowtable_net_hooks(struct net *net, - struct list_head *hook_list) +static void __nft_unregister_flowtable_net_hooks(struct net *net, + struct list_head *hook_list, + bool release_netdev) { - struct nft_hook *hook; + struct nft_hook *hook, *next; =20 - list_for_each_entry(hook, hook_list, list) + list_for_each_entry_safe(hook, next, hook_list, list) { nf_unregister_net_hook(net, &hook->ops); + if (release_netdev) { + list_del(&hook->list); + kfree_rcu(hook); + } + } +} + +static void nft_unregister_flowtable_net_hooks(struct net *net, + struct list_head *hook_list) +{ + __nft_unregister_flowtable_net_hooks(net, hook_list, false); } =20 static int nft_register_flowtable_net_hooks(struct net *net, @@ -9605,9 +9632,10 @@ static void __nft_release_hook(struct ne struct nft_chain *chain; =20 list_for_each_entry(chain, &table->chains, list) - nf_tables_unregister_hook(net, table, chain); + __nf_tables_unregister_hook(net, table, chain, true); list_for_each_entry(flowtable, &table->flowtables, list) - nft_unregister_flowtable_net_hooks(net, &flowtable->hook_list); + __nft_unregister_flowtable_net_hooks(net, &flowtable->hook_list, + true); } =20 static void __nft_release_hooks(struct net *net) From nobody Sat May 2 09:01:00 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 962CAC433EF for ; Fri, 3 Jun 2022 17:58:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344719AbiFCR6f (ORCPT ); Fri, 3 Jun 2022 13:58:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58246 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346940AbiFCRvp (ORCPT ); Fri, 3 Jun 2022 13:51:45 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4A70755358; Fri, 3 Jun 2022 10:49:50 -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 CE5B2B82189; Fri, 3 Jun 2022 17:49:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 280B0C385A9; Fri, 3 Jun 2022 17:49:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278587; bh=+jKGu2m+qotB5j1a1TjLLakeDpMh01+5nUzTVxMt6Vo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=fVo1AST0GB+siLT2VRa+Jbm61BM0AUH5uenkMDum0ff5vOQRQ5wM88B3YFQRXFYXP XXxJvhpc+W48nAifstTfZWk9LknaI8bNTLnsvr6VtE5t2BIytdg4Qg8DIDPW0m50Na Gv3MdZwcIWYraavW+UVLR4ohWQtWPnF3BGUhzHys= 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.15 27/66] netfilter: conntrack: re-fetch conntrack after insertion Date: Fri, 3 Jun 2022 19:43:07 +0200 Message-Id: <20220603173821.441752761@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos 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 @@ -58,8 +58,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 Sat May 2 09:01:00 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 419E0C43334 for ; Fri, 3 Jun 2022 18:04:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346587AbiFCSEn (ORCPT ); Fri, 3 Jun 2022 14:04:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58332 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346953AbiFCRvp (ORCPT ); Fri, 3 Jun 2022 13:51:45 -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 C67F35A2EE; Fri, 3 Jun 2022 10:49: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 490A660F70; Fri, 3 Jun 2022 17:49:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 39A03C385A9; Fri, 3 Jun 2022 17:49:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278590; bh=cFrmnNl9L7po2P5cc20mN8UGOG2sPnDsfXvs7hKmLbA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=R8lJlQfWSgPXi+yWFdnlYAOUHG+qcLVcGHcyBM/D13kbAGn5sckBYn/ld7Y3UMs3p /s98MvRt9FmCGR2BBHcADnGLKyWzJv9/nbYAx+wcjoGqsn/wp4CSjpjfy4TH9/0NtD Msuun90VT9BR/ai7ypMXY7w8eZQ34VWGqCS1h7k4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Xiaomeng Tong , Michael Ellerman Subject: [PATCH 5.15 28/66] KVM: PPC: Book3S HV: fix incorrect NULL check on list iterator Date: Fri, 3 Jun 2022 19:43:08 +0200 Message-Id: <20220603173821.469405318@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Xiaomeng Tong commit 300981abddcb13f8f06ad58f52358b53a8096775 upstream. The bug is here: if (!p) return ret; The list iterator value 'p' will *always* be set and non-NULL by list_for_each_entry(), so it is incorrect to assume that the iterator value will be NULL if the list is empty or no element is found. To fix the bug, Use a new value 'iter' as the list iterator, while use the old value 'p' as a dedicated variable to point to the found element. Fixes: dfaa973ae960 ("KVM: PPC: Book3S HV: In H_SVM_INIT_DONE, migrate rema= ining normal-GFNs to secure-GFNs") Cc: stable@vger.kernel.org # v5.9+ Signed-off-by: Xiaomeng Tong Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220414062103.8153-1-xiam0nd.tong@gmail.com Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Sudip Mukherjee --- arch/powerpc/kvm/book3s_hv_uvmem.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) --- a/arch/powerpc/kvm/book3s_hv_uvmem.c +++ b/arch/powerpc/kvm/book3s_hv_uvmem.c @@ -360,13 +360,15 @@ static bool kvmppc_gfn_is_uvmem_pfn(unsi static bool kvmppc_next_nontransitioned_gfn(const struct kvm_memory_slot *= memslot, struct kvm *kvm, unsigned long *gfn) { - struct kvmppc_uvmem_slot *p; + struct kvmppc_uvmem_slot *p =3D NULL, *iter; bool ret =3D false; unsigned long i; =20 - list_for_each_entry(p, &kvm->arch.uvmem_pfns, list) - if (*gfn >=3D p->base_pfn && *gfn < p->base_pfn + p->nr_pfns) + list_for_each_entry(iter, &kvm->arch.uvmem_pfns, list) + if (*gfn >=3D iter->base_pfn && *gfn < iter->base_pfn + iter->nr_pfns) { + p =3D iter; break; + } if (!p) return ret; /* From nobody Sat May 2 09:01:00 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 77083C433EF for ; Fri, 3 Jun 2022 17:58:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346072AbiFCR6m (ORCPT ); Fri, 3 Jun 2022 13:58:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57826 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346999AbiFCRvt (ORCPT ); Fri, 3 Jun 2022 13:51:49 -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 5CF601023; Fri, 3 Jun 2022 10:49:56 -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 DDBD0B8241E; Fri, 3 Jun 2022 17:49:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 32D8BC385A9; Fri, 3 Jun 2022 17:49:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278593; bh=4CV2YYdOdmtQY/EHPZAR8SenSGDXz6x4jpKV19cuIKQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=bqhNK/7uTqP2rLGIkVVDDRUtVZtL8dDgxHcol9rexwS3Ne1ORODOmZMKBDvvTGb6z 6zNYOQvniI0bJp9WhFRdiFZLRmb0PAcf95UtcfPKmpB0Mu5xB0hkLakEj3dU1vRgmP IYqWhMsN9eFvB+Ebi3x/RntjIwheTOB/6ZPiiBww= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Yajun Deng , Sean Christopherson , Paolo Bonzini Subject: [PATCH 5.15 29/66] x86/kvm: Alloc dummy async #PF token outside of raw spinlock Date: Fri, 3 Jun 2022 19:43:09 +0200 Message-Id: <20220603173821.498239266@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Sean Christopherson commit 0547758a6de3cc71a0cfdd031a3621a30db6a68b upstream. Drop the raw spinlock in kvm_async_pf_task_wake() before allocating the the dummy async #PF token, the allocator is preemptible on PREEMPT_RT kernels and must not be called from truly atomic contexts. Opportunistically document why it's ok to loop on allocation failure, i.e. why the function won't get stuck in an infinite loop. Reported-by: Yajun Deng Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Sudip Mukherjee --- arch/x86/kernel/kvm.c | 41 +++++++++++++++++++++++++++-------------- 1 file changed, 27 insertions(+), 14 deletions(-) --- a/arch/x86/kernel/kvm.c +++ b/arch/x86/kernel/kvm.c @@ -188,7 +188,7 @@ void kvm_async_pf_task_wake(u32 token) { u32 key =3D hash_32(token, KVM_TASK_SLEEP_HASHBITS); struct kvm_task_sleep_head *b =3D &async_pf_sleepers[key]; - struct kvm_task_sleep_node *n; + struct kvm_task_sleep_node *n, *dummy =3D NULL; =20 if (token =3D=3D ~0) { apf_task_wake_all(); @@ -200,28 +200,41 @@ again: n =3D _find_apf_task(b, token); if (!n) { /* - * async PF was not yet handled. - * Add dummy entry for the token. + * Async #PF not yet handled, add a dummy entry for the token. + * Allocating the token must be down outside of the raw lock + * as the allocator is preemptible on PREEMPT_RT kernels. */ - n =3D kzalloc(sizeof(*n), GFP_ATOMIC); - if (!n) { + if (!dummy) { + raw_spin_unlock(&b->lock); + dummy =3D kzalloc(sizeof(*dummy), GFP_KERNEL); + /* - * Allocation failed! Busy wait while other cpu - * handles async PF. + * Continue looping on allocation failure, eventually + * the async #PF will be handled and allocating a new + * node will be unnecessary. + */ + if (!dummy) + cpu_relax(); + + /* + * Recheck for async #PF completion before enqueueing + * the dummy token to avoid duplicate list entries. */ - raw_spin_unlock(&b->lock); - cpu_relax(); goto again; } - n->token =3D token; - n->cpu =3D smp_processor_id(); - init_swait_queue_head(&n->wq); - hlist_add_head(&n->link, &b->list); + dummy->token =3D token; + dummy->cpu =3D smp_processor_id(); + init_swait_queue_head(&dummy->wq); + hlist_add_head(&dummy->link, &b->list); + dummy =3D NULL; } else { apf_task_wake_one(n); } raw_spin_unlock(&b->lock); - return; + + /* A dummy token might be allocated and ultimately not used. */ + if (dummy) + kfree(dummy); } EXPORT_SYMBOL_GPL(kvm_async_pf_task_wake); From nobody Sat May 2 09:01:00 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 31A87CCA473 for ; Fri, 3 Jun 2022 18:02:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346206AbiFCSCC (ORCPT ); Fri, 3 Jun 2022 14:02:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58166 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347061AbiFCRvy (ORCPT ); Fri, 3 Jun 2022 13:51:54 -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 8698556218; Fri, 3 Jun 2022 10:50: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 ams.source.kernel.org (Postfix) with ESMTPS id 068A1B8241E; Fri, 3 Jun 2022 17:50:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7064BC385A9; Fri, 3 Jun 2022 17:49:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278599; bh=HgO/YYUBUaikVJTuqzSnhSDHKguXOeaqQnh/CGNBQlo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kZIvgJOzdu4vb0oyt6aeTWvLs6FFAoC5G0QEslT9KfsyIXMZUhDmvseyCMSaIpz04 B61ct3a4y/Axhj8rR1+Px963Kk2fhnR1XIqSDMGrn3O4fEUwkCJiGnElJBJjBD3XFs zNmr8lbTXGmyZNOTlyFQroUQ+e3V3drfTRB5/Cmo= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Dan Carpenter , Paolo Bonzini Subject: [PATCH 5.15 30/66] x86, kvm: use correct GFP flags for preemption disabled Date: Fri, 3 Jun 2022 19:43:10 +0200 Message-Id: <20220603173821.525978571@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Paolo Bonzini commit baec4f5a018fe2d708fc1022330dba04b38b5fe3 upstream. Commit ddd7ed842627 ("x86/kvm: Alloc dummy async #PF token outside of raw spinlock") leads to the following Smatch static checker warning: arch/x86/kernel/kvm.c:212 kvm_async_pf_task_wake() warn: sleeping in atomic context arch/x86/kernel/kvm.c 202 raw_spin_lock(&b->lock); 203 n =3D _find_apf_task(b, token); 204 if (!n) { 205 /* 206 * Async #PF not yet handled, add a dummy entry for= the token. 207 * Allocating the token must be down outside of the= raw lock 208 * as the allocator is preemptible on PREEMPT_RT ke= rnels. 209 */ 210 if (!dummy) { 211 raw_spin_unlock(&b->lock); --> 212 dummy =3D kzalloc(sizeof(*dummy), GFP_KERNE= L); ^^^^^^^^^^ Smatch thinks the caller has preempt disabled. The `smdb.py preempt kvm_async_pf_task_wake` output call tree is: sysvec_kvm_asyncpf_interrupt() <- disables preempt -> __sysvec_kvm_asyncpf_interrupt() -> kvm_async_pf_task_wake() The caller is this: arch/x86/kernel/kvm.c 290 DEFINE_IDTENTRY_SYSVEC(sysvec_kvm_asyncpf_interrupt) 291 { 292 struct pt_regs *old_regs =3D set_irq_regs(regs); 293 u32 token; 294 295 ack_APIC_irq(); 296 297 inc_irq_stat(irq_hv_callback_count); 298 299 if (__this_cpu_read(apf_reason.enabled)) { 300 token =3D __this_cpu_read(apf_reason.token); 301 kvm_async_pf_task_wake(token); 302 __this_cpu_write(apf_reason.token, 0); 303 wrmsrl(MSR_KVM_ASYNC_PF_ACK, 1); 304 } 305 306 set_irq_regs(old_regs); 307 } The DEFINE_IDTENTRY_SYSVEC() is a wrapper that calls this function from the call_on_irqstack_cond(). It's inside the call_on_irqstack_cond() where preempt is disabled (unless it's already disabled). The irq_enter/exit_rcu() functions disable/enable preempt. Reported-by: Dan Carpenter Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Sudip Mukherjee --- arch/x86/kernel/kvm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/x86/kernel/kvm.c +++ b/arch/x86/kernel/kvm.c @@ -206,7 +206,7 @@ again: */ if (!dummy) { raw_spin_unlock(&b->lock); - dummy =3D kzalloc(sizeof(*dummy), GFP_KERNEL); + dummy =3D kzalloc(sizeof(*dummy), GFP_ATOMIC); =20 /* * Continue looping on allocation failure, eventually From nobody Sat May 2 09:01:00 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 DC7F5C433EF for ; Fri, 3 Jun 2022 18:00:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346712AbiFCSAb (ORCPT ); Fri, 3 Jun 2022 14:00:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58130 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347102AbiFCRv5 (ORCPT ); Fri, 3 Jun 2022 13:51:57 -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 6CCB457B16; Fri, 3 Jun 2022 10:50:04 -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 8F7D760A0F; Fri, 3 Jun 2022 17:50:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7FF17C385A9; Fri, 3 Jun 2022 17:50:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278603; bh=8KN7L+80h1MHPhss4GQUQaL93QCH/hlkREk2DlXPkyI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=hcxZdG4+d/uqaXZqdAndOTdpD9oYhDmzdkvCvlGE2cIoT3xh2TYOtJC5+Z+c3xD/P 1Yy2cgacGX4dMKPhp3npZlt3Q3m/QUQaKsKLqmHK7ReRrSOb6hn67ygWfCMkZgU5EJ l3jKOh+8+zsnRUmlxq1pOREo05Gj/QpY+Vt5cgGA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Qiuhao Li , Gaoning Pan , Yongkang Jia , Sean Christopherson , Paolo Bonzini Subject: [PATCH 5.15 31/66] KVM: x86: avoid calling x86 emulator without a decoded instruction Date: Fri, 3 Jun 2022 19:43:11 +0200 Message-Id: <20220603173821.553626389@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Sean Christopherson commit fee060cd52d69c114b62d1a2948ea9648b5131f9 upstream. Whenever x86_decode_emulated_instruction() detects a breakpoint, it returns the value that kvm_vcpu_check_breakpoint() writes into its pass-by-reference second argument. Unfortunately this is completely bogus because the expected outcome of x86_decode_emulated_instruction is an EMULATION_* value. Then, if kvm_vcpu_check_breakpoint() does "*r =3D 0" (corresponding to a KVM_EXIT_DEBUG userspace exit), it is misunderstood as EMULATION_OK and x86_emulate_instruction() is called without having decoded the instruction. This causes various havoc from running with a stale emulation context. The fix is to move the call to kvm_vcpu_check_breakpoint() where it was before commit 4aa2691dcbd3 ("KVM: x86: Factor out x86 instruction emulation with decoding") introduced x86_decode_emulated_instruction(). The other caller of the function does not need breakpoint checks, because it is invoked as part of a vmexit and the processor has already checked those before executing the instruction that #GP'd. This fixes CVE-2022-1852. Reported-by: Qiuhao Li Reported-by: Gaoning Pan Reported-by: Yongkang Jia Fixes: 4aa2691dcbd3 ("KVM: x86: Factor out x86 instruction emulation with d= ecoding") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-Id: <20220311032801.3467418-2-seanjc@google.com> [Rewrote commit message according to Qiuhao's report, since a patch already existed to fix the bug. - Paolo] Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Sudip Mukherjee --- arch/x86/kvm/x86.c | 31 +++++++++++++++++++------------ 1 file changed, 19 insertions(+), 12 deletions(-) --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -7846,7 +7846,7 @@ int kvm_skip_emulated_instruction(struct } EXPORT_SYMBOL_GPL(kvm_skip_emulated_instruction); =20 -static bool kvm_vcpu_check_breakpoint(struct kvm_vcpu *vcpu, int *r) +static bool kvm_vcpu_check_code_breakpoint(struct kvm_vcpu *vcpu, int *r) { if (unlikely(vcpu->guest_debug & KVM_GUESTDBG_USE_HW_BP) && (vcpu->arch.guest_debug_dr7 & DR7_BP_EN_MASK)) { @@ -7915,25 +7915,23 @@ static bool is_vmware_backdoor_opcode(st } =20 /* - * Decode to be emulated instruction. Return EMULATION_OK if success. + * Decode an instruction for emulation. The caller is responsible for han= dling + * code breakpoints. Note, manually detecting code breakpoints is unneces= sary + * (and wrong) when emulating on an intercepted fault-like exception[*], as + * code breakpoints have higher priority and thus have already been done by + * hardware. + * + * [*] Except #MC, which is higher priority, but KVM should never emulate = in + * response to a machine check. */ int x86_decode_emulated_instruction(struct kvm_vcpu *vcpu, int emulation_t= ype, void *insn, int insn_len) { - int r =3D EMULATION_OK; struct x86_emulate_ctxt *ctxt =3D vcpu->arch.emulate_ctxt; + int r; =20 init_emulate_ctxt(vcpu); =20 - /* - * We will reenter on the same instruction since we do not set - * complete_userspace_io. This does not handle watchpoints yet, - * those would be handled in the emulate_ops. - */ - if (!(emulation_type & EMULTYPE_SKIP) && - kvm_vcpu_check_breakpoint(vcpu, &r)) - return r; - r =3D x86_decode_insn(ctxt, insn, insn_len, emulation_type); =20 trace_kvm_emulate_insn_start(vcpu); @@ -7966,6 +7964,15 @@ int x86_emulate_instruction(struct kvm_v if (!(emulation_type & EMULTYPE_NO_DECODE)) { kvm_clear_exception_queue(vcpu); =20 + /* + * Return immediately if RIP hits a code breakpoint, such #DBs + * are fault-like and are higher priority than any faults on + * the code fetch itself. + */ + if (!(emulation_type & EMULTYPE_SKIP) && + kvm_vcpu_check_code_breakpoint(vcpu, &r)) + return r; + r =3D x86_decode_emulated_instruction(vcpu, emulation_type, insn, insn_len); if (r !=3D EMULATION_OK) { From nobody Sat May 2 09:01:00 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 975F4C43334 for ; Fri, 3 Jun 2022 17:58:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345986AbiFCR6u (ORCPT ); Fri, 3 Jun 2022 13:58:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58232 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347162AbiFCRwE (ORCPT ); Fri, 3 Jun 2022 13:52:04 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8F6C0580C7; Fri, 3 Jun 2022 10:50:08 -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 1F946B8241E; Fri, 3 Jun 2022 17:50:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6A35FC385B8; Fri, 3 Jun 2022 17:50:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278605; bh=L9NL8cfQm4uBAI+EBhlVPB/EEPK4z9XyUAwqdOPAGPQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=wp3Wju6qe6pxG3XXramIEwdjjFD1VxRz3zVTVNlEM+MRsgt4Pe5iiAZuMDrOmWGJc nC3dK6+dF4+NmQh21Y2Utjs3HbzYTx661GEnu5btIv0T50kDxqPdHk7sK1q/U3/f+L x0P+S2I9W5F0/hntf/nGzynGWsl4GCcu5cVwtPyI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Chenyi Qiang , Sean Christopherson , Paolo Bonzini Subject: [PATCH 5.15 32/66] KVM: x86: Drop WARNs that assert a triple fault never "escapes" from L2 Date: Fri, 3 Jun 2022 19:43:12 +0200 Message-Id: <20220603173821.581325065@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Sean Christopherson commit 45846661d10422ce9e22da21f8277540b29eca22 upstream. Remove WARNs that sanity check that KVM never lets a triple fault for L2 escape and incorrectly end up in L1. In normal operation, the sanity check is perfectly valid, but it incorrectly assumes that it's impossible for userspace to induce KVM_REQ_TRIPLE_FAULT without bouncing through KVM_RUN (which guarantees kvm_check_nested_state() will see and handle the triple fault). The WARN can currently be triggered if userspace injects a machine check while L2 is active and CR4.MCE=3D0. And a future fix to allow save/restore of KVM_REQ_TRIPLE_FAULT, e.g. so that a synthesized triple fault isn't lost on migration, will make it trivially easy for userspace to trigger the WARN. Clearing KVM_REQ_TRIPLE_FAULT when forcibly leaving guest mode is tempting, but wrong, especially if/when the request is saved/restored, e.g. if userspace restores events (including a triple fault) and then restores nested state (which may forcibly leave guest mode). Ignoring the fact that KVM doesn't currently provide the necessary APIs, it's userspace's responsibility to manage pending events during save/restore. ------------[ cut here ]------------ WARNING: CPU: 7 PID: 1399 at arch/x86/kvm/vmx/nested.c:4522 nested_vmx_vm= exit+0x7fe/0xd90 [kvm_intel] Modules linked in: kvm_intel kvm irqbypass CPU: 7 PID: 1399 Comm: state_test Not tainted 5.17.0-rc3+ #808 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:nested_vmx_vmexit+0x7fe/0xd90 [kvm_intel] Call Trace: vmx_leave_nested+0x30/0x40 [kvm_intel] vmx_set_nested_state+0xca/0x3e0 [kvm_intel] kvm_arch_vcpu_ioctl+0xf49/0x13e0 [kvm] kvm_vcpu_ioctl+0x4b9/0x660 [kvm] __x64_sys_ioctl+0x83/0xb0 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae ---[ end trace 0000000000000000 ]--- Fixes: cb6a32c2b877 ("KVM: x86: Handle triple fault in L2 without killing L= 1") Cc: stable@vger.kernel.org Cc: Chenyi Qiang Signed-off-by: Sean Christopherson Message-Id: <20220407002315.78092-2-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Sudip Mukherjee --- arch/x86/kvm/svm/nested.c | 3 --- arch/x86/kvm/vmx/nested.c | 3 --- 2 files changed, 6 deletions(-) --- a/arch/x86/kvm/svm/nested.c +++ b/arch/x86/kvm/svm/nested.c @@ -750,9 +750,6 @@ int nested_svm_vmexit(struct vcpu_svm *s struct kvm_host_map map; int rc; =20 - /* Triple faults in L2 should never escape. */ - WARN_ON_ONCE(kvm_check_request(KVM_REQ_TRIPLE_FAULT, vcpu)); - rc =3D kvm_vcpu_map(vcpu, gpa_to_gfn(svm->nested.vmcb12_gpa), &map); if (rc) { if (rc =3D=3D -EINVAL) --- a/arch/x86/kvm/vmx/nested.c +++ b/arch/x86/kvm/vmx/nested.c @@ -4501,9 +4501,6 @@ void nested_vmx_vmexit(struct kvm_vcpu * /* trying to cancel vmlaunch/vmresume is a bug */ WARN_ON_ONCE(vmx->nested.nested_run_pending); =20 - /* Similarly, triple faults in L2 should never escape. */ - WARN_ON_ONCE(kvm_check_request(KVM_REQ_TRIPLE_FAULT, vcpu)); - if (kvm_check_request(KVM_REQ_GET_NESTED_STATE_PAGES, vcpu)) { /* * KVM_REQ_GET_NESTED_STATE_PAGES is also used to map From nobody Sat May 2 09:01:00 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 9DEFBCCA48A for ; Fri, 3 Jun 2022 18:00:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346570AbiFCSAZ (ORCPT ); Fri, 3 Jun 2022 14:00:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58038 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347163AbiFCRwE (ORCPT ); Fri, 3 Jun 2022 13:52:04 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AC9C3580CC; Fri, 3 Jun 2022 10:50: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 dfw.source.kernel.org (Postfix) with ESMTPS id 48D3460EE9; Fri, 3 Jun 2022 17:50:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 59AD4C385A9; Fri, 3 Jun 2022 17:50:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278608; bh=g5yfTco7inUmJg9Rw/AeKnYQZPpNl5xGBDN2emXMj14=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=2dVKdtEUMsopahMf0vRrldFiRl1Ctyax9Iz7EE7fMjaZFpJEf1edPGM4mR+BCTQzw FgNk+QwgKPnBdUgJWEGxWp/MAzk8eYzc49vhyK1e9UUP1HF5m+Eaifdd9+mXordwkd 1AnHrlyhcrNRnKM+GuJdyWbbH7uZ0WrjlJpZyZd4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Andy Nguyen , David Rientjes , Peter Gonda , kvm@vger.kernel.org, Ashish Kalra , Paolo Bonzini Subject: [PATCH 5.15 33/66] KVM: SVM: Use kzalloc for sev ioctl interfaces to prevent kernel data leak Date: Fri, 3 Jun 2022 19:43:13 +0200 Message-Id: <20220603173821.609177091@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Ashish Kalra commit d22d2474e3953996f03528b84b7f52cc26a39403 upstream. For some sev ioctl interfaces, the length parameter that is passed maybe less than or equal to SEV_FW_BLOB_MAX_SIZE, but larger than the data that PSP firmware returns. In this case, kmalloc will allocate memory that is the size of the input rather than the size of the data. Since PSP firmware doesn't fully overwrite the allocated buffer, these sev ioctl interface may return uninitialized kernel slab memory. Reported-by: Andy Nguyen Suggested-by: David Rientjes Suggested-by: Peter Gonda Cc: kvm@vger.kernel.org Cc: stable@vger.kernel.org Cc: linux-kernel@vger.kernel.org Fixes: eaf78265a4ab3 ("KVM: SVM: Move SEV code to separate file") Fixes: 2c07ded06427d ("KVM: SVM: add support for SEV attestation command") Fixes: 4cfdd47d6d95a ("KVM: SVM: Add KVM_SEV SEND_START command") Fixes: d3d1af85e2c75 ("KVM: SVM: Add KVM_SEND_UPDATE_DATA command") Fixes: eba04b20e4861 ("KVM: x86: Account a variety of miscellaneous allocat= ions") Signed-off-by: Ashish Kalra Reviewed-by: Peter Gonda Message-Id: <20220516154310.3685678-1-Ashish.Kalra@amd.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Sudip Mukherjee --- arch/x86/kvm/svm/sev.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -676,7 +676,7 @@ static int sev_launch_measure(struct kvm if (params.len > SEV_FW_BLOB_MAX_SIZE) return -EINVAL; =20 - blob =3D kmalloc(params.len, GFP_KERNEL_ACCOUNT); + blob =3D kzalloc(params.len, GFP_KERNEL_ACCOUNT); if (!blob) return -ENOMEM; =20 @@ -796,7 +796,7 @@ static int __sev_dbg_decrypt_user(struct if (!IS_ALIGNED(dst_paddr, 16) || !IS_ALIGNED(paddr, 16) || !IS_ALIGNED(size, 16)) { - tpage =3D (void *)alloc_page(GFP_KERNEL); + tpage =3D (void *)alloc_page(GFP_KERNEL | __GFP_ZERO); if (!tpage) return -ENOMEM; =20 @@ -1082,7 +1082,7 @@ static int sev_get_attestation_report(st if (params.len > SEV_FW_BLOB_MAX_SIZE) return -EINVAL; =20 - blob =3D kmalloc(params.len, GFP_KERNEL_ACCOUNT); + blob =3D kzalloc(params.len, GFP_KERNEL_ACCOUNT); if (!blob) return -ENOMEM; =20 @@ -1164,7 +1164,7 @@ static int sev_send_start(struct kvm *kv return -EINVAL; =20 /* allocate the memory to hold the session data blob */ - session_data =3D kmalloc(params.session_len, GFP_KERNEL_ACCOUNT); + session_data =3D kzalloc(params.session_len, GFP_KERNEL_ACCOUNT); if (!session_data) return -ENOMEM; =20 @@ -1288,11 +1288,11 @@ static int sev_send_update_data(struct k =20 /* allocate memory for header and transport buffer */ ret =3D -ENOMEM; - hdr =3D kmalloc(params.hdr_len, GFP_KERNEL_ACCOUNT); + hdr =3D kzalloc(params.hdr_len, GFP_KERNEL_ACCOUNT); if (!hdr) goto e_unpin; =20 - trans_data =3D kmalloc(params.trans_len, GFP_KERNEL_ACCOUNT); + trans_data =3D kzalloc(params.trans_len, GFP_KERNEL_ACCOUNT); if (!trans_data) goto e_free_hdr; From nobody Sat May 2 09:01:00 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 A4747C43334 for ; Fri, 3 Jun 2022 18:03:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346346AbiFCSDr (ORCPT ); Fri, 3 Jun 2022 14:03:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58166 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347278AbiFCRwM (ORCPT ); Fri, 3 Jun 2022 13:52:12 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EE323167F2; Fri, 3 Jun 2022 10:52: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 ams.source.kernel.org (Postfix) with ESMTPS id A2B5CB8241D; Fri, 3 Jun 2022 17:52:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F08CEC385A9; Fri, 3 Jun 2022 17:52:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278728; bh=tSQXz/ZFbI2pYTh4TigjjrPwJuuXCKdaX9A7q3dypck=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=sE7lE9Y/Byeitk28kV0m5CxmgRS+dy7Ql5GMXlAs/w/RYonMdLubsw2dOsQXfDCUD oMlR5QoyjkQqY1MqOhKFRYwz3EH7ciJl/GO6h3JLsR1iE3pKnzPgqfzc58kp/2mssN iRo+1RTCjh5dLGk6eFaIT15354QGGlU/I9Su9Thw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Fabio Estevam , =?UTF-8?q?Horia=20Geant=C4=83?= , Vabhav Sharma , Gaurav Jain , Herbert Xu Subject: [PATCH 5.15 34/66] crypto: caam - fix i.MX6SX entropy delay value Date: Fri, 3 Jun 2022 19:43:14 +0200 Message-Id: <20220603173821.637268293@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Fabio Estevam commit 4ee4cdad368a26de3967f2975806a9ee2fa245df upstream. Since commit 358ba762d9f1 ("crypto: caam - enable prediction resistance in HRWNG") the following CAAM errors can be seen on i.MX6SX: caam_jr 2101000.jr: 20003c5b: CCB: desc idx 60: RNG: Hardware error hwrng: no data available This error is due to an incorrect entropy delay for i.MX6SX. Fix it by increasing the minimum entropy delay for i.MX6SX as done in U-Boot: https://patchwork.ozlabs.org/project/uboot/patch/20220415111049.2565744-1-g= aurav.jain@nxp.com/ As explained in the U-Boot patch: "RNG self tests are run to determine the correct entropy delay. Such tests are executed with different voltages and temperatures to identify the worst case value for the entropy delay. For i.MX6SX, it was determined that after adding a margin value of 1000 the minimum entropy delay should be at least 12000." Cc: Fixes: 358ba762d9f1 ("crypto: caam - enable prediction resistance in HRWNG") Signed-off-by: Fabio Estevam Reviewed-by: Horia Geant=C4=83 Reviewed-by: Vabhav Sharma Reviewed-by: Gaurav Jain Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Sudip Mukherjee --- drivers/crypto/caam/ctrl.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) --- a/drivers/crypto/caam/ctrl.c +++ b/drivers/crypto/caam/ctrl.c @@ -609,6 +609,13 @@ static bool check_version(struct fsl_mc_ } #endif =20 +static bool needs_entropy_delay_adjustment(void) +{ + if (of_machine_is_compatible("fsl,imx6sx")) + return true; + return false; +} + /* Probe routine for CAAM top (controller) level */ static int caam_probe(struct platform_device *pdev) { @@ -855,6 +862,8 @@ static int caam_probe(struct platform_de * Also, if a handle was instantiated, do not change * the TRNG parameters. */ + if (needs_entropy_delay_adjustment()) + ent_delay =3D 12000; if (!(ctrlpriv->rng4_sh_init || inst_handles)) { dev_info(dev, "Entropy delay =3D %u\n", @@ -871,6 +880,15 @@ static int caam_probe(struct platform_de */ ret =3D instantiate_rng(dev, inst_handles, gen_sk); + /* + * Entropy delay is determined via TRNG characterization. + * TRNG characterization is run across different voltages + * and temperatures. + * If worst case value for ent_dly is identified, + * the loop can be skipped for that platform. + */ + if (needs_entropy_delay_adjustment()) + break; if (ret =3D=3D -EAGAIN) /* * if here, the loop will rerun, From nobody Sat May 2 09:01:00 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 6A72DCCA483 for ; Fri, 3 Jun 2022 18:00:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346631AbiFCSA2 (ORCPT ); Fri, 3 Jun 2022 14:00:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58344 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347219AbiFCRwI (ORCPT ); Fri, 3 Jun 2022 13:52:08 -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 4AA63562DA; Fri, 3 Jun 2022 10:50:33 -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 DB9FC60EE9; Fri, 3 Jun 2022 17:50:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E75FDC3411C; Fri, 3 Jun 2022 17:50:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278632; bh=sQ0GPSl5NoQwPN9POfGGNsMy+Sxch4CTIxQGvcHIVJU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=uNVmtlsI96A2wYZ40DU+Fu95l8C8eENXStboWnRUCz6hUHomfdAO4CncSQ0WEhN7r nxWsKZCsFx+UikUYP4tKKnMB5krM0yM4VE0+qwsVcliIXcXlfLyUylvSBD2K4E0kLM YvLdPUaNX0Z7fGRycTcG8Iuv/wGEFPUgFyy4ky1s= 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.15 35/66] crypto: ecrdsa - Fix incorrect use of vli_cmp Date: Fri, 3 Jun 2022 19:43:15 +0200 Message-Id: <20220603173821.665178127@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Sudip Mukherjee --- crypto/ecrdsa.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) --- a/crypto/ecrdsa.c +++ b/crypto/ecrdsa.c @@ -113,15 +113,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; @@ -137,7 +137,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 Sat May 2 09:01:00 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 46772CCA488 for ; Fri, 3 Jun 2022 18:00:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347006AbiFCSAu (ORCPT ); Fri, 3 Jun 2022 14:00:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58230 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347240AbiFCRwK (ORCPT ); Fri, 3 Jun 2022 13:52:10 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F009C6455; Fri, 3 Jun 2022 10:51:06 -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 A344AB82419; Fri, 3 Jun 2022 17:51:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 126FAC385A9; Fri, 3 Jun 2022 17:51:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278664; bh=ry2C3eARotAq5FGIRgqxgdjpHkZxCcBRsV2WwinOtyo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ZrqpSvYsPcQue7DJD2ZQhFUjSIPHJ5aZd4DjLLS8VPF+9fCu54G0OIDwg9dhsSESx UxPZUsyFelSlnqQgfIv+J0IqU4spTGnyMyv9PR3wLj/GtnkhoaXCfbwBuW9cJk77Ht 72KCnFegF0sMaZo2KdylZ5n6iK5ytn+63hiw6nQQ= 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.15 36/66] zsmalloc: fix races between asynchronous zspage free and page migration Date: Fri, 3 Jun 2022 19:43:16 +0200 Message-Id: <20220603173821.693014834@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Sudip Mukherjee --- mm/zsmalloc.c | 37 +++++++++++++++++++++++++++++++++---- 1 file changed, 33 insertions(+), 4 deletions(-) --- a/mm/zsmalloc.c +++ b/mm/zsmalloc.c @@ -1743,11 +1743,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 Sat May 2 09:01:00 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 A226EC433EF for ; Fri, 3 Jun 2022 18:03:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346318AbiFCSDA (ORCPT ); Fri, 3 Jun 2022 14:03:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58428 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347261AbiFCRwK (ORCPT ); Fri, 3 Jun 2022 13:52:10 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3DBE9B48E; Fri, 3 Jun 2022 10:51:40 -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 E2770B82419; Fri, 3 Jun 2022 17:51:38 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 23348C385A9; Fri, 3 Jun 2022 17:51:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278697; bh=u3IpJg7f52QEmZoiTs+geEPRmnLMhe+3HVFYgwUxjcA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=hCd/MzFWqOlhokl60z4HvVU0yO5QWcVXR0dbscJAdiT1HfLDu+eGfYnKMwGxZ46I+ cHTNsEk5iw5O999Jd1IpeuZaAftUO4XqLDUW6rQP8375u0+Uzup75YcX+1fGFAE73p Pn9Dyem6r+BKFWCBZmyF8k9bpy4w0tPbc6B9bBTI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Takashi Iwai , Maris Abele Subject: [PATCH 5.15 37/66] ALSA: usb-audio: Workaround for clock setup on TEAC devices Date: Fri, 3 Jun 2022 19:43:17 +0200 Message-Id: <20220603173821.742820192@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Takashi Iwai commit 5ce0b06ae5e69e23142e73c5c3c0260e9f2ccb4b upstream. Maris reported that TEAC UD-501 (0644:8043) doesn't work with the typical "clock source 41 is not valid, cannot use" errors on the recent kernels. The currently known workaround so far is to restore (partially) what we've done unconditionally at the clock setup; namely, re-setup the USB interface immediately after the clock is changed. This patch re-introduces the behavior conditionally for TEAC devices. Further notes: - The USB interface shall be set later in snd_usb_endpoint_configure(), but this seems to be too late. - Even calling usb_set_interface() right after sne_usb_init_sample_rate() doesn't help; so this must be related with the clock validation, too. - The device may still spew the "clock source 41 is not valid" error at the first clock setup. This seems happening at the very first try of clock setup, but it disappears at later attempts. The error is likely harmless because the driver retries the clock setup (such an error is more or less expected on some devices). Fixes: bf6313a0ff76 ("ALSA: usb-audio: Refactor endpoint management") Reported-and-tested-by: Maris Abele Cc: Link: https://lore.kernel.org/r/20220521064627.29292-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Sudip Mukherjee --- sound/usb/clock.c | 7 +++++++ 1 file changed, 7 insertions(+) --- a/sound/usb/clock.c +++ b/sound/usb/clock.c @@ -572,6 +572,13 @@ static int set_sample_rate_v2v3(struct s /* continue processing */ } =20 + /* FIXME - TEAC devices require the immediate interface setup */ + if (rate !=3D prev_rate && USB_ID_VENDOR(chip->usb_id) =3D=3D 0x0644) { + usb_set_interface(chip->dev, fmt->iface, fmt->altsetting); + if (chip->quirk_flags & QUIRK_FLAG_IFACE_DELAY) + msleep(50); + } + validation: /* validate clock after rate change */ if (!uac_clock_source_is_valid(chip, fmt, clock)) From nobody Sat May 2 09:01:00 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 965A8C43334 for ; Fri, 3 Jun 2022 18:04:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346552AbiFCSEZ (ORCPT ); Fri, 3 Jun 2022 14:04:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58168 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347267AbiFCRwK (ORCPT ); Fri, 3 Jun 2022 13:52:10 -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 BC92812AAC; Fri, 3 Jun 2022 10:51: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 ams.source.kernel.org (Postfix) with ESMTPS id 73F7EB82189; Fri, 3 Jun 2022 17:51:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A565EC385B8; Fri, 3 Jun 2022 17:51:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278710; bh=k8dwY4UsBqEZIeUNq0npNOB1aRN/HTu4O5GznizTuIE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=olCYCKnAmKbKRQrp4JbJ/RcMfMHq2bfsV52Szyv2OPGkf/VA3yXZKbfF3nWAIvhCE zsHJc5PLrkCD5MydxrvnGnnGwZOePnolN53Lkj5fVg297W821LCry8rM3QMy5sN6iy aBz4lwdf4GfXr/ibLA8PevDSCBxlePtM0m++yGRo= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, =?UTF-8?q?Andr=C3=A9=20Kapelrud?= , Takashi Iwai Subject: [PATCH 5.15 38/66] ALSA: usb-audio: Add missing ep_idx in fixed EP quirks Date: Fri, 3 Jun 2022 19:43:18 +0200 Message-Id: <20220603173821.775056441@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Takashi Iwai commit 7b0efea4baf02f5e2f89e5f9b75ef891571b45f1 upstream. The quirk entry for Focusrite Saffire 6 had no proper ep_idx for the capture endpoint, and this confused the driver, resulting in the broken sound. This patch adds the missing ep_idx in the entry. While we are at it, a couple of other entries (for Digidesign MBox and MOTU MicroBook II) seem to have the same problem, and those are covered as well. Fixes: bf6313a0ff76 ("ALSA: usb-audio: Refactor endpoint management") Reported-by: Andr=C3=A9 Kapelrud Cc: Link: https://lore.kernel.org/r/20220521065325.426-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Sudip Mukherjee --- sound/usb/quirks-table.h | 3 +++ 1 file changed, 3 insertions(+) --- a/sound/usb/quirks-table.h +++ b/sound/usb/quirks-table.h @@ -2672,6 +2672,7 @@ YAMAHA_DEVICE(0x7010, "UB99"), .altset_idx =3D 1, .attributes =3D 0, .endpoint =3D 0x82, + .ep_idx =3D 1, .ep_attr =3D USB_ENDPOINT_XFER_ISOC, .datainterval =3D 1, .maxpacksize =3D 0x0126, @@ -2875,6 +2876,7 @@ YAMAHA_DEVICE(0x7010, "UB99"), .altset_idx =3D 1, .attributes =3D 0x4, .endpoint =3D 0x81, + .ep_idx =3D 1, .ep_attr =3D USB_ENDPOINT_XFER_ISOC | USB_ENDPOINT_SYNC_ASYNC, .maxpacksize =3D 0x130, @@ -3391,6 +3393,7 @@ YAMAHA_DEVICE(0x7010, "UB99"), .altset_idx =3D 1, .attributes =3D 0, .endpoint =3D 0x03, + .ep_idx =3D 1, .rates =3D SNDRV_PCM_RATE_96000, .ep_attr =3D USB_ENDPOINT_XFER_ISOC | USB_ENDPOINT_SYNC_ASYNC, From nobody Sat May 2 09:01:00 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 296E0C43334 for ; Fri, 3 Jun 2022 18:03:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242725AbiFCSDc (ORCPT ); Fri, 3 Jun 2022 14:03:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58420 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347270AbiFCRwK (ORCPT ); Fri, 3 Jun 2022 13:52:10 -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 A3B8113D16; Fri, 3 Jun 2022 10:51: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 67851B82419; Fri, 3 Jun 2022 17:51:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BEB3CC385A9; Fri, 3 Jun 2022 17:51:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278713; bh=xF4TwzXvI/vuD2ZvHNLqd2yjZu07Y0fkHy+dpnoz9IY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=wkDp1dJcD5SSNhf+DLlVz8jsBdsVQMLkBxRErVY6TFjTiR2xOZW0zG6al8MXiuo4J WDdy5VGovXDMNSVVH+M0H5N86BWkTlfSMoAXrwuc1pTguTKKpCkFepVzPcqsycE/sl 0ndQq5z8VKpMrN+kTtE6bP6Gb1fVZpToOOiBhoH0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Craig McLure , Jaroslav Kysela , Takashi Iwai Subject: [PATCH 5.15 39/66] ALSA: usb-audio: Configure sync endpoints before data Date: Fri, 3 Jun 2022 19:43:19 +0200 Message-Id: <20220603173821.802500760@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Craig McLure commit 0e85a22d01dfe9ad9a9d9e87cd4a88acce1aad65 upstream. Devices such as the TC-Helicon GoXLR require the sync endpoint to be configured in advance of the data endpoint in order for sound output to work. This patch simply changes the ordering of EP configuration to resolve this. Fixes: bf6313a0ff76 ("ALSA: usb-audio: Refactor endpoint management") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=3D215079 Signed-off-by: Craig McLure Reviewed-by: Jaroslav Kysela Cc: Link: https://lore.kernel.org/r/20220524062115.25968-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Sudip Mukherjee --- sound/usb/pcm.c | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c index 6d699065e81a..b470404a5376 100644 --- a/sound/usb/pcm.c +++ b/sound/usb/pcm.c @@ -439,16 +439,21 @@ static int configure_endpoints(struct snd_usb_audio *= chip, /* stop any running stream beforehand */ if (stop_endpoints(subs, false)) sync_pending_stops(subs); + if (subs->sync_endpoint) { + err =3D snd_usb_endpoint_configure(chip, subs->sync_endpoint); + if (err < 0) + return err; + } err =3D snd_usb_endpoint_configure(chip, subs->data_endpoint); if (err < 0) return err; snd_usb_set_format_quirk(subs, subs->cur_audiofmt); - } - - if (subs->sync_endpoint) { - err =3D snd_usb_endpoint_configure(chip, subs->sync_endpoint); - if (err < 0) - return err; + } else { + if (subs->sync_endpoint) { + err =3D snd_usb_endpoint_configure(chip, subs->sync_endpoint); + if (err < 0) + return err; + } } =20 return 0; --=20 2.36.1 From nobody Sat May 2 09:01:00 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 3D0DAC433EF for ; Fri, 3 Jun 2022 18:04:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346519AbiFCSEJ (ORCPT ); Fri, 3 Jun 2022 14:04:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57792 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347275AbiFCRwL (ORCPT ); Fri, 3 Jun 2022 13:52: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 2504713E9C; Fri, 3 Jun 2022 10:51: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 B687D60F3B; Fri, 3 Jun 2022 17:51:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BF593C385B8; Fri, 3 Jun 2022 17:51:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278716; bh=tfgjU31NPL+z9713wFziaUtlFoPM/QCEwzK8ujtven8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=uV01uIL7yYahrUm1ov4hLIijDLv7R3wkQioVpB1uBQpXeUrN/pMicQQN5+rhELHHb YVBxtUFaGASQb/k3wNBGF7/VWrU1qewwrGXWBxbg+q40OePh7AplRaf78Jwts3RVwl 3+hbfckBOXTgtITSFYbMAq0FUs0P0yAFXHKM4r1A= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Eric Dumazet , "Steven Rostedt (Google)" , Marcel Holtmann Subject: [PATCH 5.15 40/66] Bluetooth: hci_qca: Use del_timer_sync() before freeing Date: Fri, 3 Jun 2022 19:43:20 +0200 Message-Id: <20220603173821.830759872@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Steven Rostedt commit 72ef98445aca568a81c2da050532500a8345ad3a upstream. While looking at a crash report on a timer list being corrupted, which usually happens when a timer is freed while still active. This is commonly triggered by code calling del_timer() instead of del_timer_sync() just before freeing. One possible culprit is the hci_qca driver, which does exactly that. Eric mentioned that wake_retrans_timer could be rearmed via the work queue, so also move the destruction of the work queue before del_timer_sync(). Cc: Eric Dumazet Cc: stable@vger.kernel.org Fixes: 0ff252c1976da ("Bluetooth: hciuart: Add support QCA chipset for UART= ") Signed-off-by: Steven Rostedt (Google) Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Sudip Mukherjee --- drivers/bluetooth/hci_qca.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/bluetooth/hci_qca.c +++ b/drivers/bluetooth/hci_qca.c @@ -696,9 +696,9 @@ static int qca_close(struct hci_uart *hu skb_queue_purge(&qca->tx_wait_q); skb_queue_purge(&qca->txq); skb_queue_purge(&qca->rx_memdump_q); - del_timer(&qca->tx_idle_timer); - del_timer(&qca->wake_retrans_timer); destroy_workqueue(qca->workqueue); + del_timer_sync(&qca->tx_idle_timer); + del_timer_sync(&qca->wake_retrans_timer); qca->hu =3D NULL; =20 kfree_skb(qca->rx_skb); From nobody Sat May 2 09:01:00 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 780DFC433EF for ; Fri, 3 Jun 2022 18:03:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346502AbiFCSDz (ORCPT ); Fri, 3 Jun 2022 14:03:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58332 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347274AbiFCRwL (ORCPT ); Fri, 3 Jun 2022 13:52:11 -0400 Received: from sin.source.kernel.org (sin.source.kernel.org [IPv6:2604:1380:40e1:4800::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D9B1F15703; Fri, 3 Jun 2022 10:52: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 sin.source.kernel.org (Postfix) with ESMTPS id 92C1DCE247C; Fri, 3 Jun 2022 17:52:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9E13DC385A9; Fri, 3 Jun 2022 17:51:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278719; bh=/EyG57P4jtW4RHdb3WPUV5f8lPpG5g2cOM8KMHmq+5w=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=PyvNMzbqsFmvp6q52Sk5FBIWuMIT3pcOiVwtaUdBPM25EfEF4eYA0aGj0DD3vlzBU eCbgKkhsNCzAThg6kr+GWrLFWTz35Fw6CPotwq3qHbrV3wDVDNfiDfx/SrNUrVJqrb QIaqLgsWZXMApUk4zw6Ns2B+Oj5+g1IM6K1Pm+2Y= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jonathan Bakker , Krzysztof Kozlowski Subject: [PATCH 5.15 41/66] ARM: dts: s5pv210: Correct interrupt name for bluetooth in Aries Date: Fri, 3 Jun 2022 19:43:21 +0200 Message-Id: <20220603173821.858530708@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Jonathan Bakker commit 3f5e3d3a8b895c8a11da8b0063ba2022dd9e2045 upstream. Correct the name of the bluetooth interrupt from host-wake to host-wakeup. Fixes: 1c65b6184441b ("ARM: dts: s5pv210: Correct BCM4329 bluetooth node") Cc: Signed-off-by: Jonathan Bakker Link: https://lore.kernel.org/r/CY4PR04MB0567495CFCBDC8D408D44199CB1C9@CY4P= R04MB0567.namprd04.prod.outlook.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Sudip Mukherjee --- arch/arm/boot/dts/s5pv210-aries.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/arm/boot/dts/s5pv210-aries.dtsi +++ b/arch/arm/boot/dts/s5pv210-aries.dtsi @@ -895,7 +895,7 @@ device-wakeup-gpios =3D <&gpg3 4 GPIO_ACTIVE_HIGH>; interrupt-parent =3D <&gph2>; interrupts =3D <5 IRQ_TYPE_LEVEL_HIGH>; - interrupt-names =3D "host-wake"; + interrupt-names =3D "host-wakeup"; }; }; From nobody Sat May 2 09:01:00 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 C097EC43334 for ; Fri, 3 Jun 2022 18:04:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235509AbiFCSEE (ORCPT ); Fri, 3 Jun 2022 14:04:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58444 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347271AbiFCRwL (ORCPT ); Fri, 3 Jun 2022 13:52: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 D525C15827; Fri, 3 Jun 2022 10:52:04 -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 942A6B82419; Fri, 3 Jun 2022 17:52:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D8E93C385B8; Fri, 3 Jun 2022 17:52:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278722; bh=o2LDBO1b8iC0wppgbfky3VEsUppuRsfLKRLQ/QY0Rq4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=lTHiS+P9cMABSI8lTg/Qt3eSm/Mh7x1rKvAwFx+O7e9iDKZhqPbsP8NWt0IKQpAyu zei09popk0qU7RaUoPkdX7wknScJrdjx1eYN4g37mEuC/SneZsOZr5SVzPhjfgJipt yB+9rNYjrEJjdMTeU7BqdJEx98fkqNpkFQHmB+Vs= 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.15 42/66] dm integrity: fix error code in dm_integrity_ctr() Date: Fri, 3 Jun 2022 19:43:22 +0200 Message-Id: <20220603173821.886142555@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos 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 @@ -4478,8 +4478,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 Sat May 2 09:01:00 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 C537DC433EF for ; Fri, 3 Jun 2022 18:04:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346489AbiFCSEQ (ORCPT ); Fri, 3 Jun 2022 14:04:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58104 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347272AbiFCRwL (ORCPT ); Fri, 3 Jun 2022 13:52:11 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B19BC1658C; Fri, 3 Jun 2022 10:52:07 -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 72385B823B0; Fri, 3 Jun 2022 17:52:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DA9F3C385A9; Fri, 3 Jun 2022 17:52:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278725; bh=1SlBnX28+eG2G8boXWkKy1sUzm7l7jBS747wX8oyWIA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GADpbnR1oobMdRwb00sTjq5/VX6qn+vfw8mZ37dYG+GDGMlToLrqH7kvuIW9S5tTL wVf25bTrTtKJsjejU3k/4197ENnyzmPKGFr7+1E7yLVW8xgX2yh7bIK/Nb2PmWKxdL X6r+0ZP5iz7eg4G7Eh61MLCCpVCYyAkyfYQpX3wE= 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.15 43/66] dm crypt: make printing of the key constant-time Date: Fri, 3 Jun 2022 19:43:23 +0200 Message-Id: <20220603173821.914690184@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos 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 @@ -3435,6 +3435,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) { @@ -3453,9 +3458,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 Sat May 2 09:01:00 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 AACC8CCA47C for ; Fri, 3 Jun 2022 18:01:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243480AbiFCSB2 (ORCPT ); Fri, 3 Jun 2022 14:01:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58600 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347225AbiFCRwI (ORCPT ); Fri, 3 Jun 2022 13:52:08 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2F41B562E9; Fri, 3 Jun 2022 10:50: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 B723A60EE9; Fri, 3 Jun 2022 17:50:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BEF9FC385B8; Fri, 3 Jun 2022 17:50:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278635; bh=8Zu7MjpXWW9lQAoYnVgd0XW5X1hTwM+Sak8w4dzHC0g=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=XcqYFcU0ojKGcqyT5+TpFfyVBO/1y1LNYbqX6D5OpnRErYwb5dGpFN93ecCbLxX+h HFG2+7DTA21k0q11YX9ztwhjfLmLUzKECits3g/1Mrq4g9TUo1PIiPUo/Anuk2PPhD Hm4yqf9VSa25qFoqwSTsiYPl33qmTK8F11jwnFsE= 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.15 44/66] dm stats: add cond_resched when looping over entries Date: Fri, 3 Jun 2022 19:43:24 +0200 Message-Id: <20220603173821.942579769@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos 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 @@ -225,6 +225,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); } @@ -330,6 +331,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) { @@ -342,6 +344,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 @@ -362,6 +365,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(); } } } @@ -497,6 +501,7 @@ static int dm_stats_list(struct dm_stats } DMEMIT("\n"); } + cond_resched(); } mutex_unlock(&stats->mutex); =20 @@ -774,6 +779,7 @@ static void __dm_stat_clear(struct dm_st local_irq_enable(); } } + cond_resched(); } } =20 @@ -889,6 +895,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 Sat May 2 09:01:00 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 F29A9CCA484 for ; Fri, 3 Jun 2022 18:00:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346789AbiFCSAe (ORCPT ); Fri, 3 Jun 2022 14:00:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58124 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347224AbiFCRwI (ORCPT ); Fri, 3 Jun 2022 13:52:08 -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 A7E59B51; Fri, 3 Jun 2022 10:50:40 -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 4F0B1B82189; Fri, 3 Jun 2022 17:50:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B8CF1C385A9; Fri, 3 Jun 2022 17:50:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278638; bh=TNIMVPaeLJ/QcWDFFqjeA42a5Y4yMf8PXuFOQY86fbU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=UZI3HHBLq+ghQ5h0W1OOl+36pjYHESV/bjmdpwnL2JBJNqQdApO5RRHcO7cUfE+Xz 1u3oO3tR9753jSeDS/QBgMW9EyKAtMQ1exe9MmcYl9GJUDY3RGtFckWH4f9wVyCLLC 5Bv90vaXCMcxVHrBXE6QlSYmW74qjEoLa0IZR8dE= 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.15 45/66] dm verity: set DM_TARGET_IMMUTABLE feature flag Date: Fri, 3 Jun 2022 19:43:25 +0200 Message-Id: <20220603173821.970033877@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos 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 @@ -1312,6 +1312,7 @@ bad: =20 static struct target_type verity_target =3D { .name =3D "verity", + .features =3D DM_TARGET_IMMUTABLE, .version =3D {1, 8, 0}, .module =3D THIS_MODULE, .ctr =3D verity_ctr, From nobody Sat May 2 09:01:00 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 C9A52CCA47E for ; Fri, 3 Jun 2022 18:01:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231251AbiFCSBB (ORCPT ); Fri, 3 Jun 2022 14:01:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58122 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347230AbiFCRwI (ORCPT ); Fri, 3 Jun 2022 13:52:08 -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 C25C132E; Fri, 3 Jun 2022 10:50: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 7B6FEB82419; Fri, 3 Jun 2022 17:50:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C58B1C385A9; Fri, 3 Jun 2022 17:50:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278641; bh=YrXhbiJph5afatE3srEUKuLmWGYAxVpDpkaWS5nFUjw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=IF6s2I/u2/q0yDCdMNSoCJTI1NEJQ2bXhrbmy1tu9g7cQe+BLAu+Rt66KrAm0s1cb Y9ItHMdhwKK00OCju+sg2xFKqBfCzSiw3AsCQ0wvPRiK0JHi9Ulh3NdD8IywKwghKp Rg7rFS25QDuHrpftlIUwyGuOduXnUzwjqIBP+kHU= 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.15 46/66] raid5: introduce MD_BROKEN Date: Fri, 3 Jun 2022 19:43:26 +0200 Message-Id: <20220603173821.998035862@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos 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 @@ -686,17 +686,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 * @@ -2877,34 +2877,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 Sat May 2 09:01:00 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 D9F93C433EF for ; Fri, 3 Jun 2022 18:01:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346330AbiFCSBG (ORCPT ); Fri, 3 Jun 2022 14:01:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58138 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347228AbiFCRwI (ORCPT ); Fri, 3 Jun 2022 13:52:08 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DDBA7B54; Fri, 3 Jun 2022 10:50:46 -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 979F7B82189; Fri, 3 Jun 2022 17:50:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C1F54C385A9; Fri, 3 Jun 2022 17:50:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278644; bh=EPBHgmukQQ2kavRRx6NFY8j/vcnjOWl5lgESjAPm9W8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=U4t7hFXaFvOoLuUOsdcZ2cZ6R001qTr6TsRXR1o+mi9a6rjFrrYg9vkD8wF3zLL2I cTBW1TPqXLxJ5H8EYDRO1dUJEujKeCwCiTa0Ffb2uun531xGrSzfSuHUUkrLBOLMsZ GBr7DsLBNtwgxQkQ8OTYAP7n/60FqOMEytmf59k0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Randy Dunlap , syzbot+1631f09646bc214d2e76@syzkaller.appspotmail.com, Namjae Jeon , Konstantin Komarov , Alexander Viro , Kari Argillander , Matthew Wilcox , Andrew Morton Subject: [PATCH 5.15 47/66] fs/ntfs3: validate BOOT sectors_per_clusters Date: Fri, 3 Jun 2022 19:43:27 +0200 Message-Id: <20220603173822.025720768@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Randy Dunlap commit a3b774342fa752a5290c0de36375289dfcf4a260 upstream. When the NTFS BOOT sectors_per_clusters field is > 0x80, it represents a shift value. Make sure that the shift value is not too large before using it (NTFS max cluster size is 2MB). Return -EVINVAL if it too large. This prevents negative shift values and shift values that are larger than the field size. Prevents this UBSAN error: UBSAN: shift-out-of-bounds in ../fs/ntfs3/super.c:673:16 shift exponent -192 is negative Link: https://lkml.kernel.org/r/20220502175342.20296-1-rdunlap@infradead.org Fixes: 82cae269cfa9 ("fs/ntfs3: Add initialization of super block") Signed-off-by: Randy Dunlap Reported-by: syzbot+1631f09646bc214d2e76@syzkaller.appspotmail.com Reviewed-by: Namjae Jeon Cc: Konstantin Komarov Cc: Alexander Viro Cc: Kari Argillander Cc: Namjae Jeon Cc: Matthew Wilcox Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Sudip Mukherjee --- fs/ntfs3/super.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) --- a/fs/ntfs3/super.c +++ b/fs/ntfs3/super.c @@ -668,9 +668,11 @@ static u32 format_size_gb(const u64 byte =20 static u32 true_sectors_per_clst(const struct NTFS_BOOT *boot) { - return boot->sectors_per_clusters <=3D 0x80 - ? boot->sectors_per_clusters - : (1u << (0 - boot->sectors_per_clusters)); + if (boot->sectors_per_clusters <=3D 0x80) + return boot->sectors_per_clusters; + if (boot->sectors_per_clusters >=3D 0xf4) /* limit shift to 2MB max */ + return 1U << (0 - boot->sectors_per_clusters); + return -EINVAL; } =20 /* @@ -713,6 +715,8 @@ static int ntfs_init_from_boot(struct su =20 /* cluster size: 512, 1K, 2K, 4K, ... 2M */ sct_per_clst =3D true_sectors_per_clst(boot); + if ((int)sct_per_clst < 0) + goto out; if (!is_power_of_2(sct_per_clst)) goto out; From nobody Sat May 2 09:01:00 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 B5B14C433EF for ; Fri, 3 Jun 2022 18:01:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346105AbiFCSBo (ORCPT ); Fri, 3 Jun 2022 14:01:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58040 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347223AbiFCRwI (ORCPT ); Fri, 3 Jun 2022 13:52:08 -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 BE1ADB82; Fri, 3 Jun 2022 10:50: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 7A751B823B0; Fri, 3 Jun 2022 17:50:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D3775C385B8; Fri, 3 Jun 2022 17:50:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278647; bh=py7W3K5TMchg50vXQHrYE7WTrD96cuiq7L66aU9VY4s=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kj6Y+ndUlti7M4i9DLGljlmxq8c1XgtlXNkOzlOooVx8jV5FhS9ZBxiTAw6qfcr+d LMwLsYZEreTdgdHQK6mDYO2TPAQet3NQrMwI5F+5d1CJoNA8B676z1oizQZ9G4X7Dx 42KhmnElGzBL9qqt+cJwAJAXeCI6Bui0E02GrpK0= 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.15 48/66] HID: multitouch: Add support for Google Whiskers Touchpad Date: Fri, 3 Jun 2022 19:43:28 +0200 Message-Id: <20220603173822.054005560@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos 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 @@ -2176,6 +2176,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 Sat May 2 09:01:00 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 2F522CCA487 for ; Fri, 3 Jun 2022 18:00:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346932AbiFCSAp (ORCPT ); Fri, 3 Jun 2022 14:00:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58154 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347231AbiFCRwI (ORCPT ); Fri, 3 Jun 2022 13:52:08 -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 90B01CC6; Fri, 3 Jun 2022 10:50: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 ams.source.kernel.org (Postfix) with ESMTPS id 4A774B82419; Fri, 3 Jun 2022 17:50:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 98409C385A9; Fri, 3 Jun 2022 17:50:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278650; bh=UoYgQFgAeQun6qyKQWi73uIHFyzu7x4V9H4PVuQYoos=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=oJ6/Sg1vurzizsbCoQ6/G8NFNfcxvjer3oYfeK5YFbqdT1L4BASEYGiaq0gj5+4Ww R5c1/0PyEMQEHdxzYzKp0QN3A6LZ/lfXGe2kstKXzKrhpX0LPcV/+0rlXXq8RVVwaD MfqPISi64/r65yo2JJFyIqUd8xmRJRxr7UymssO0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Tao Jin , Benjamin Tissoires Subject: [PATCH 5.15 49/66] HID: multitouch: add quirks to enable Lenovo X12 trackpoint Date: Fri, 3 Jun 2022 19:43:29 +0200 Message-Id: <20220603173822.082302091@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Tao Jin commit 95cd2cdc88c755dcd0a58b951faeb77742c733a4 upstream. This applies the similar quirks used by previous generation devices such as X1 tablet for X12 tablet, so that the trackpoint and buttons can work. This patch was applied and tested working on 5.17.1 . Cc: stable@vger.kernel.org # 5.8+ given that it relies on 40d5bb87377a Signed-off-by: Tao Jin Signed-off-by: Benjamin Tissoires Link: https://lore.kernel.org/r/CO6PR03MB6241CB276FCDC7F4CEDC34F6E1E29@CO6P= R03MB6241.namprd03.prod.outlook.com Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Sudip Mukherjee --- drivers/hid/hid-ids.h | 1 + drivers/hid/hid-multitouch.c | 6 ++++++ 2 files changed, 7 insertions(+) --- a/drivers/hid/hid-ids.h +++ b/drivers/hid/hid-ids.h @@ -753,6 +753,7 @@ #define USB_DEVICE_ID_LENOVO_X1_COVER 0x6085 #define USB_DEVICE_ID_LENOVO_X1_TAB 0x60a3 #define USB_DEVICE_ID_LENOVO_X1_TAB3 0x60b5 +#define USB_DEVICE_ID_LENOVO_X12_TAB 0x60fe #define USB_DEVICE_ID_LENOVO_OPTICAL_USB_MOUSE_600E 0x600e #define USB_DEVICE_ID_LENOVO_PIXART_USB_MOUSE_608D 0x608d #define USB_DEVICE_ID_LENOVO_PIXART_USB_MOUSE_6019 0x6019 --- a/drivers/hid/hid-multitouch.c +++ b/drivers/hid/hid-multitouch.c @@ -2032,6 +2032,12 @@ static const struct hid_device_id mt_dev USB_VENDOR_ID_LENOVO, USB_DEVICE_ID_LENOVO_X1_TAB3) }, =20 + /* Lenovo X12 TAB Gen 1 */ + { .driver_data =3D MT_CLS_WIN_8_FORCE_MULTI_INPUT, + HID_DEVICE(BUS_USB, HID_GROUP_MULTITOUCH_WIN_8, + USB_VENDOR_ID_LENOVO, + USB_DEVICE_ID_LENOVO_X12_TAB) }, + /* MosArt panels */ { .driver_data =3D MT_CLS_CONFIDENCE_MINUS_ONE, MT_USB_DEVICE(USB_VENDOR_ID_ASUS, From nobody Sat May 2 09:01:00 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 C4A4BC433EF for ; Fri, 3 Jun 2022 18:01:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345775AbiFCSBQ (ORCPT ); Fri, 3 Jun 2022 14:01:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58596 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347226AbiFCRwI (ORCPT ); Fri, 3 Jun 2022 13:52:08 -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 48ED7F25; Fri, 3 Jun 2022 10:50: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 0BAFDB823B0; Fri, 3 Jun 2022 17:50:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 677A7C385A9; Fri, 3 Jun 2022 17:50:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278652; bh=0prqloLrALboBqYx7GfVhCOuXhFihqnnhoizcnn15Pc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Lo/x2PSzYmImbEn+IGYQwxaCQyDiPB4HA6nCecSe7VA91IuvWs6oQuewqCYXQMu26 fSlpCLmZRvR6plPajG8S023X/ySIK1zWMvSHJhlIgZkqpjLZxw6wzJr3hKM/t+w/bs 85JirLI7qBU75kkyZ7FO+e0iKiAANjgoKy5kMjqw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Dave Hansen , Reinette Chatre , Jarkko Sakkinen , Haitao Huang Subject: [PATCH 5.15 50/66] x86/sgx: Disconnect backing page references from dirty status Date: Fri, 3 Jun 2022 19:43:30 +0200 Message-Id: <20220603173822.111314857@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Reinette Chatre commit 6bd429643cc265e94a9d19839c771bcc5d008fa8 upstream. SGX uses shmem backing storage to store encrypted enclave pages and their crypto metadata when enclave pages are moved out of enclave memory. Two shmem backing storage pages are associated with each enclave page - one backing page to contain the encrypted enclave page data and one backing page (shared by a few enclave pages) to contain the crypto metadata used by the processor to verify the enclave page when it is loaded back into the enclave. sgx_encl_put_backing() is used to release references to the backing storage and, optionally, mark both backing store pages as dirty. Managing references and dirty status together in this way results in both backing store pages marked as dirty, even if only one of the backing store pages are changed. Additionally, waiting until the page reference is dropped to set the page dirty risks a race with the page fault handler that may load outdated data into the enclave when a page is faulted right after it is reclaimed. Consider what happens if the reclaimer writes a page to the backing store and the page is immediately faulted back, before the reclaimer is able to set the dirty bit of the page: sgx_reclaim_pages() { sgx_vma_fault() { ... sgx_encl_get_backing(); ... ... sgx_reclaimer_write() { mutex_lock(&encl->lock); /* Write data to backing store */ mutex_unlock(&encl->lock); } mutex_lock(&encl->lock); __sgx_encl_eldu() { ... /* * Enclave backing store * page not released * nor marked dirty - * contents may not be * up to date. */ sgx_encl_get_backing(); ... /* * Enclave data restored * from backing store * and PCMD pages that * are not up to date. * ENCLS[ELDU] faults * because of MAC or PCMD * checking failure. */ sgx_encl_put_backing(); } ... /* set page dirty */ sgx_encl_put_backing(); ... mutex_unlock(&encl->lock); } } Remove the option to sgx_encl_put_backing() to set the backing pages as dirty and set the needed pages as dirty right after receiving important data while enclave mutex is held. This ensures that the page fault handler can get up to date data from a page and prepares the code for a following change where only one of the backing pages need to be marked as dirty. Cc: stable@vger.kernel.org Fixes: 1728ab54b4be ("x86/sgx: Add a page reclaimer") Suggested-by: Dave Hansen Signed-off-by: Reinette Chatre Signed-off-by: Dave Hansen Reviewed-by: Jarkko Sakkinen Tested-by: Haitao Huang Link: https://lore.kernel.org/linux-sgx/8922e48f-6646-c7cc-6393-7c78dcf23d2= 3@intel.com/ Link: https://lkml.kernel.org/r/fa9f98986923f43e72ef4c6702a50b2a0b3c42e3.16= 52389823.git.reinette.chatre@intel.com Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Sudip Mukherjee --- arch/x86/kernel/cpu/sgx/encl.c | 10 ++-------- arch/x86/kernel/cpu/sgx/encl.h | 2 +- arch/x86/kernel/cpu/sgx/main.c | 6 ++++-- 3 files changed, 7 insertions(+), 11 deletions(-) --- a/arch/x86/kernel/cpu/sgx/encl.c +++ b/arch/x86/kernel/cpu/sgx/encl.c @@ -94,7 +94,7 @@ static int __sgx_encl_eldu(struct sgx_en kunmap_atomic(pcmd_page); kunmap_atomic((void *)(unsigned long)pginfo.contents); =20 - sgx_encl_put_backing(&b, false); + sgx_encl_put_backing(&b); =20 sgx_encl_truncate_backing_page(encl, page_index); =20 @@ -645,15 +645,9 @@ int sgx_encl_get_backing(struct sgx_encl /** * sgx_encl_put_backing() - Unpin the backing storage * @backing: data for accessing backing storage for the page - * @do_write: mark pages dirty */ -void sgx_encl_put_backing(struct sgx_backing *backing, bool do_write) +void sgx_encl_put_backing(struct sgx_backing *backing) { - if (do_write) { - set_page_dirty(backing->pcmd); - set_page_dirty(backing->contents); - } - put_page(backing->pcmd); put_page(backing->contents); } --- a/arch/x86/kernel/cpu/sgx/encl.h +++ b/arch/x86/kernel/cpu/sgx/encl.h @@ -107,7 +107,7 @@ void sgx_encl_release(struct kref *ref); int sgx_encl_mm_add(struct sgx_encl *encl, struct mm_struct *mm); int sgx_encl_get_backing(struct sgx_encl *encl, unsigned long page_index, struct sgx_backing *backing); -void sgx_encl_put_backing(struct sgx_backing *backing, bool do_write); +void sgx_encl_put_backing(struct sgx_backing *backing); int sgx_encl_test_and_clear_young(struct mm_struct *mm, struct sgx_encl_page *page); =20 --- a/arch/x86/kernel/cpu/sgx/main.c +++ b/arch/x86/kernel/cpu/sgx/main.c @@ -170,6 +170,8 @@ static int __sgx_encl_ewb(struct sgx_epc backing->pcmd_offset; =20 ret =3D __ewb(&pginfo, sgx_get_epc_virt_addr(epc_page), va_slot); + set_page_dirty(backing->pcmd); + set_page_dirty(backing->contents); =20 kunmap_atomic((void *)(unsigned long)(pginfo.metadata - backing->pcmd_offset)); @@ -299,7 +301,7 @@ static void sgx_reclaimer_write(struct s sgx_encl_free_epc_page(encl->secs.epc_page); encl->secs.epc_page =3D NULL; =20 - sgx_encl_put_backing(&secs_backing, true); + sgx_encl_put_backing(&secs_backing); } =20 out: @@ -392,7 +394,7 @@ skip: =20 encl_page =3D epc_page->owner; sgx_reclaimer_write(epc_page, &backing[i]); - sgx_encl_put_backing(&backing[i], true); + sgx_encl_put_backing(&backing[i]); =20 kref_put(&encl_page->encl->refcount, sgx_encl_release); epc_page->flags &=3D ~SGX_EPC_PAGE_RECLAIMER_TRACKED; From nobody Sat May 2 09:01:00 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 AEB8FCCA48B for ; Fri, 3 Jun 2022 18:00:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347137AbiFCSA4 (ORCPT ); Fri, 3 Jun 2022 14:00:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58034 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347232AbiFCRwI (ORCPT ); Fri, 3 Jun 2022 13:52:08 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A74DF25FA; Fri, 3 Jun 2022 10:50:56 -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 4406C60EE9; Fri, 3 Jun 2022 17:50:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3F9B4C385A9; Fri, 3 Jun 2022 17:50:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278655; bh=jRGYaec2MuAtdgELoc6FWEItHG4GgkCI+meBt12+l9A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=huf/d0mrMZjmxejAXFrzwsdzw9KCrRDMF3P8EHgOUxUWRWMXSN29r8vm0jzRzGNFr inCUyQqK5MbaFE8lZf6QlQoZSAu0wSUjfsJjk2zPMt+J2pln/2U8R5UDPtBwdzpAmg Bp4x94ldttO95iy4BjWGiULYon0xztoW8mxFMfQA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Reinette Chatre , Dave Hansen , Jarkko Sakkinen , Haitao Huang Subject: [PATCH 5.15 51/66] x86/sgx: Mark PCMD page as dirty when modifying contents Date: Fri, 3 Jun 2022 19:43:31 +0200 Message-Id: <20220603173822.139892667@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Reinette Chatre commit 2154e1c11b7080aa19f47160bd26b6f39bbd7824 upstream. Recent commit 08999b2489b4 ("x86/sgx: Free backing memory after faulting the enclave page") expanded __sgx_encl_eldu() to clear an enclave page's PCMD (Paging Crypto MetaData) from the PCMD page in the backing store after the enclave page is restored to the enclave. Since the PCMD page in the backing store is modified the page should be marked as dirty to ensure the modified data is retained. Cc: stable@vger.kernel.org Fixes: 08999b2489b4 ("x86/sgx: Free backing memory after faulting the encla= ve page") Signed-off-by: Reinette Chatre Signed-off-by: Dave Hansen Reviewed-by: Jarkko Sakkinen Tested-by: Haitao Huang Link: https://lkml.kernel.org/r/00cd2ac480db01058d112e347b32599c1a806bc4.16= 52389823.git.reinette.chatre@intel.com Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Sudip Mukherjee --- arch/x86/kernel/cpu/sgx/encl.c | 1 + 1 file changed, 1 insertion(+) --- a/arch/x86/kernel/cpu/sgx/encl.c +++ b/arch/x86/kernel/cpu/sgx/encl.c @@ -84,6 +84,7 @@ static int __sgx_encl_eldu(struct sgx_en } =20 memset(pcmd_page + b.pcmd_offset, 0, sizeof(struct sgx_pcmd)); + set_page_dirty(b.pcmd); =20 /* * The area for the PCMD in the page was zeroed above. Check if the From nobody Sat May 2 09:01:00 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 5B8E6CCA486 for ; Fri, 3 Jun 2022 18:00:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347071AbiFCSAx (ORCPT ); Fri, 3 Jun 2022 14:00:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58296 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347238AbiFCRwK (ORCPT ); Fri, 3 Jun 2022 13:52:10 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A7FB9267F; Fri, 3 Jun 2022 10:50:59 -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 43CEF60F38; Fri, 3 Jun 2022 17:50:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4A93EC385A9; Fri, 3 Jun 2022 17:50:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278658; bh=mZknYQHj+Cdjluyp0jB4qVFI4izZ1I3mhdKnzaqlxis=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=fkgZ9vGD8yNr0h7Nfsig8SsTD//6dUssXbgkm7lPwZjMVAaUzou0+7xsgXI+wNBom JDrCUDpMLQoJZ92xJF6EjqcRdOdksNGr40fcKW9Fwo+IIueY06Sn6BMAbcJk8oXLS/ +ERAlmVqD5wBExuNDihncVZ6eZxFQLkgbMPChyuI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Haitao Huang , Reinette Chatre , Dave Hansen , Jarkko Sakkinen Subject: [PATCH 5.15 52/66] x86/sgx: Obtain backing storage page with enclave mutex held Date: Fri, 3 Jun 2022 19:43:32 +0200 Message-Id: <20220603173822.167472373@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Reinette Chatre commit 0e4e729a830c1e7f31d3b3fbf8feb355a402b117 upstream. Haitao reported encountering a WARN triggered by the ENCLS[ELDU] instruction faulting with a #GP. The WARN is encountered when the reclaimer evicts a range of pages from the enclave when the same pages are faulted back right away. The SGX backing storage is accessed on two paths: when there are insufficient free pages in the EPC the reclaimer works to move enclave pages to the backing storage and as enclaves access pages that have been moved to the backing storage they are retrieved from there as part of page fault handling. An oversubscribed SGX system will often run the reclaimer and page fault handler concurrently and needs to ensure that the backing store is accessed safely between the reclaimer and the page fault handler. This is not the case because the reclaimer accesses the backing store without the enclave mutex while the page fault handler accesses the backing store with the enclave mutex. Consider the scenario where a page is faulted while a page sharing a PCMD page with the faulted page is being reclaimed. The consequence is a race between the reclaimer and page fault handler, the reclaimer attempting to access a PCMD at the same time it is truncated by the page fault handler. This could result in lost PCMD data. Data may still be lost if the reclaimer wins the race, this is addressed in the following patch. The reclaimer accesses pages from the backing storage without holding the enclave mutex and runs the risk of concurrently accessing the backing storage with the page fault handler that does access the backing storage with the enclave mutex held. In the scenario below a PCMD page is truncated from the backing store after all its pages have been loaded in to the enclave at the same time the PCMD page is loaded from the backing store when one of its pages are reclaimed: sgx_reclaim_pages() { sgx_vma_fault() { ... mutex_lock(&encl->lock); ... __sgx_encl_eldu() { ... if (pcmd_page_empty) { /* * EPC page being reclaimed /* * shares a PCMD page with an * PCMD page truncated * enclave page that is being * while requested from * faulted in. * reclaimer. */ */ sgx_encl_get_backing() <----------> sgx_encl_truncate_backing_page() } mutex_unlock(&encl->lock); } } In this scenario there is a race between the reclaimer and the page fault handler when the reclaimer attempts to get access to the same PCMD page that is being truncated. This could result in the reclaimer writing to the PCMD page that is then truncated, causing the PCMD data to be lost, or in a new PCMD page being allocated. The lost PCMD data may still occur after protecting the backing store access with the mutex - this is fixed in the next patch. By ensuring the backing store is accessed with the mutex held the enclave page state can be made accurate with the SGX_ENCL_PAGE_BEING_RECLAIMED flag accurately reflecting that a page is in the process of being reclaimed. Consistently protect the reclaimer's backing store access with the enclave's mutex to ensure that it can safely run concurrently with the page fault handler. Cc: stable@vger.kernel.org Fixes: 1728ab54b4be ("x86/sgx: Add a page reclaimer") Reported-by: Haitao Huang Signed-off-by: Reinette Chatre Signed-off-by: Dave Hansen Reviewed-by: Jarkko Sakkinen Tested-by: Jarkko Sakkinen Tested-by: Haitao Huang Link: https://lkml.kernel.org/r/fa2e04c561a8555bfe1f4e7adc37d60efc77387b.16= 52389823.git.reinette.chatre@intel.com Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Sudip Mukherjee --- arch/x86/kernel/cpu/sgx/main.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) --- a/arch/x86/kernel/cpu/sgx/main.c +++ b/arch/x86/kernel/cpu/sgx/main.c @@ -289,6 +289,7 @@ static void sgx_reclaimer_write(struct s sgx_encl_ewb(epc_page, backing); encl_page->epc_page =3D NULL; encl->secs_child_cnt--; + sgx_encl_put_backing(backing); =20 if (!encl->secs_child_cnt && test_bit(SGX_ENCL_INITIALIZED, &encl->flags)= ) { ret =3D sgx_encl_get_backing(encl, PFN_DOWN(encl->size), @@ -362,11 +363,14 @@ static void sgx_reclaim_pages(void) goto skip; =20 page_index =3D PFN_DOWN(encl_page->desc - encl_page->encl->base); + + mutex_lock(&encl_page->encl->lock); ret =3D sgx_encl_get_backing(encl_page->encl, page_index, &backing[i]); - if (ret) + if (ret) { + mutex_unlock(&encl_page->encl->lock); goto skip; + } =20 - mutex_lock(&encl_page->encl->lock); encl_page->desc |=3D SGX_ENCL_PAGE_BEING_RECLAIMED; mutex_unlock(&encl_page->encl->lock); continue; @@ -394,7 +398,6 @@ skip: =20 encl_page =3D epc_page->owner; sgx_reclaimer_write(epc_page, &backing[i]); - sgx_encl_put_backing(&backing[i]); =20 kref_put(&encl_page->encl->refcount, sgx_encl_release); epc_page->flags &=3D ~SGX_EPC_PAGE_RECLAIMER_TRACKED; From nobody Sat May 2 09:01:00 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 E921BC433EF for ; Fri, 3 Jun 2022 18:02:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346249AbiFCSCK (ORCPT ); Fri, 3 Jun 2022 14:02:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58044 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347242AbiFCRwK (ORCPT ); Fri, 3 Jun 2022 13:52:10 -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 0EB652BDE; Fri, 3 Jun 2022 10:51:04 -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 C7DF7B823B0; Fri, 3 Jun 2022 17:51:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3AAB2C385A9; Fri, 3 Jun 2022 17:51:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278661; bh=gu/GON9TB219Xl36FcW1sJOa2e8mHgE4PmzKh6ejERI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=q+tjueWLKju94s11SxEEpQP7Qe7vN0rRo97FNIBDETYOzbu3jmM5KQDFvXLnkIXED PL36G5PdMFkrFUbV8zpfMnfQLLHVWSSqHMpBVgEduAfndOViuXamH58n9T//Uei1fH OEQt1EAxB0BQ2TzqqkP9/AnAUc8gfqTW/EspRCEE= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Haitao Huang , Reinette Chatre , Dave Hansen , Jarkko Sakkinen Subject: [PATCH 5.15 53/66] x86/sgx: Fix race between reclaimer and page fault handler Date: Fri, 3 Jun 2022 19:43:33 +0200 Message-Id: <20220603173822.195105971@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Reinette Chatre commit af117837ceb9a78e995804ade4726ad2c2c8981f upstream. Haitao reported encountering a WARN triggered by the ENCLS[ELDU] instruction faulting with a #GP. The WARN is encountered when the reclaimer evicts a range of pages from the enclave when the same pages are faulted back right away. Consider two enclave pages (ENCLAVE_A and ENCLAVE_B) sharing a PCMD page (PCMD_AB). ENCLAVE_A is in the enclave memory and ENCLAVE_B is in the backing store. PCMD_AB contains just one entry, that of ENCLAVE_B. Scenario proceeds where ENCLAVE_A is being evicted from the enclave while ENCLAVE_B is faulted in. sgx_reclaim_pages() { ... /* * Reclaim ENCLAVE_A */ mutex_lock(&encl->lock); /* * Get a reference to ENCLAVE_A's * shmem page where enclave page * encrypted data will be stored * as well as a reference to the * enclave page's PCMD data page, * PCMD_AB. * Release mutex before writing * any data to the shmem pages. */ sgx_encl_get_backing(...); encl_page->desc |=3D SGX_ENCL_PAGE_BEING_RECLAIMED; mutex_unlock(&encl->lock); /* * Fault ENCLAVE_B */ sgx_vma_fault() { mutex_lock(&encl->lock); /* * Get reference to * ENCLAVE_B's shmem page * as well as PCMD_AB. */ sgx_encl_get_backing(...) /* * Load page back into * enclave via ELDU. */ /* * Release reference to * ENCLAVE_B' shmem page and * PCMD_AB. */ sgx_encl_put_backing(...); /* * PCMD_AB is found empty so * it and ENCLAVE_B's shmem page * are truncated. */ /* Truncate ENCLAVE_B backing page */ sgx_encl_truncate_backing_page(); /* Truncate PCMD_AB */ sgx_encl_truncate_backing_page(); mutex_unlock(&encl->lock); ... } mutex_lock(&encl->lock); encl_page->desc &=3D ~SGX_ENCL_PAGE_BEING_RECLAIMED; /* * Write encrypted contents of * ENCLAVE_A to ENCLAVE_A shmem * page and its PCMD data to * PCMD_AB. */ sgx_encl_put_backing(...) /* * Reference to PCMD_AB is * dropped and it is truncated. * ENCLAVE_A's PCMD data is lost. */ mutex_unlock(&encl->lock); } What happens next depends on whether it is ENCLAVE_A being faulted in or ENCLAVE_B being evicted - but both end up with ENCLS[ELDU] faulting with a #GP. If ENCLAVE_A is faulted then at the time sgx_encl_get_backing() is called a new PCMD page is allocated and providing the empty PCMD data for ENCLAVE_A would cause ENCLS[ELDU] to #GP If ENCLAVE_B is evicted first then a new PCMD_AB would be allocated by the reclaimer but later when ENCLAVE_A is faulted the ENCLS[ELDU] instruction would #GP during its checks of the PCMD value and the WARN would be encountered. Noting that the reclaimer sets SGX_ENCL_PAGE_BEING_RECLAIMED at the time it obtains a reference to the backing store pages of an enclave page it is in the process of reclaiming, fix the race by only truncating the PCMD page after ensuring that no page sharing the PCMD page is in the process of being reclaimed. Cc: stable@vger.kernel.org Fixes: 08999b2489b4 ("x86/sgx: Free backing memory after faulting the encla= ve page") Reported-by: Haitao Huang Signed-off-by: Reinette Chatre Signed-off-by: Dave Hansen Reviewed-by: Jarkko Sakkinen Tested-by: Haitao Huang Link: https://lkml.kernel.org/r/ed20a5db516aa813873268e125680041ae11dfcf.16= 52389823.git.reinette.chatre@intel.com Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Sudip Mukherjee --- arch/x86/kernel/cpu/sgx/encl.c | 94 ++++++++++++++++++++++++++++++++++++= ++++- 1 file changed, 93 insertions(+), 1 deletion(-) --- a/arch/x86/kernel/cpu/sgx/encl.c +++ b/arch/x86/kernel/cpu/sgx/encl.c @@ -12,6 +12,92 @@ #include "encls.h" #include "sgx.h" =20 +#define PCMDS_PER_PAGE (PAGE_SIZE / sizeof(struct sgx_pcmd)) +/* + * 32 PCMD entries share a PCMD page. PCMD_FIRST_MASK is used to + * determine the page index associated with the first PCMD entry + * within a PCMD page. + */ +#define PCMD_FIRST_MASK GENMASK(4, 0) + +/** + * reclaimer_writing_to_pcmd() - Query if any enclave page associated with + * a PCMD page is in process of being reclai= med. + * @encl: Enclave to which PCMD page belongs + * @start_addr: Address of enclave page using first entry within the PCMD= page + * + * When an enclave page is reclaimed some Paging Crypto MetaData (PCMD) is + * stored. The PCMD data of a reclaimed enclave page contains enough + * information for the processor to verify the page at the time + * it is loaded back into the Enclave Page Cache (EPC). + * + * The backing storage to which enclave pages are reclaimed is laid out as + * follows: + * Encrypted enclave pages:SECS page:PCMD pages + * + * Each PCMD page contains the PCMD metadata of + * PAGE_SIZE/sizeof(struct sgx_pcmd) enclave pages. + * + * A PCMD page can only be truncated if it is (a) empty, and (b) not in the + * process of getting data (and thus soon being non-empty). (b) is tested = with + * a check if an enclave page sharing the PCMD page is in the process of b= eing + * reclaimed. + * + * The reclaimer sets the SGX_ENCL_PAGE_BEING_RECLAIMED flag when it + * intends to reclaim that enclave page - it means that the PCMD page + * associated with that enclave page is about to get some data and thus + * even if the PCMD page is empty, it should not be truncated. + * + * Context: Enclave mutex (&sgx_encl->lock) must be held. + * Return: 1 if the reclaimer is about to write to the PCMD page + * 0 if the reclaimer has no intention to write to the PCMD page + */ +static int reclaimer_writing_to_pcmd(struct sgx_encl *encl, + unsigned long start_addr) +{ + int reclaimed =3D 0; + int i; + + /* + * PCMD_FIRST_MASK is based on number of PCMD entries within + * PCMD page being 32. + */ + BUILD_BUG_ON(PCMDS_PER_PAGE !=3D 32); + + for (i =3D 0; i < PCMDS_PER_PAGE; i++) { + struct sgx_encl_page *entry; + unsigned long addr; + + addr =3D start_addr + i * PAGE_SIZE; + + /* + * Stop when reaching the SECS page - it does not + * have a page_array entry and its reclaim is + * started and completed with enclave mutex held so + * it does not use the SGX_ENCL_PAGE_BEING_RECLAIMED + * flag. + */ + if (addr =3D=3D encl->base + encl->size) + break; + + entry =3D xa_load(&encl->page_array, PFN_DOWN(addr)); + if (!entry) + continue; + + /* + * VA page slot ID uses same bit as the flag so it is important + * to ensure that the page is not already in backing store. + */ + if (entry->epc_page && + (entry->desc & SGX_ENCL_PAGE_BEING_RECLAIMED)) { + reclaimed =3D 1; + break; + } + } + + return reclaimed; +} + /* * Calculate byte offset of a PCMD struct associated with an enclave page.= PCMD's * follow right after the EPC data in the backing storage. In addition to = the @@ -47,6 +133,7 @@ static int __sgx_encl_eldu(struct sgx_en unsigned long va_offset =3D encl_page->desc & SGX_ENCL_PAGE_VA_OFFSET_MAS= K; struct sgx_encl *encl =3D encl_page->encl; pgoff_t page_index, page_pcmd_off; + unsigned long pcmd_first_page; struct sgx_pageinfo pginfo; struct sgx_backing b; bool pcmd_page_empty; @@ -58,6 +145,11 @@ static int __sgx_encl_eldu(struct sgx_en else page_index =3D PFN_DOWN(encl->size); =20 + /* + * Address of enclave page using the first entry within the PCMD page. + */ + pcmd_first_page =3D PFN_PHYS(page_index & ~PCMD_FIRST_MASK) + encl->base; + page_pcmd_off =3D sgx_encl_get_backing_page_pcmd_offset(encl, page_index); =20 ret =3D sgx_encl_get_backing(encl, page_index, &b); @@ -99,7 +191,7 @@ static int __sgx_encl_eldu(struct sgx_en =20 sgx_encl_truncate_backing_page(encl, page_index); =20 - if (pcmd_page_empty) + if (pcmd_page_empty && !reclaimer_writing_to_pcmd(encl, pcmd_first_page)) sgx_encl_truncate_backing_page(encl, PFN_DOWN(page_pcmd_off)); =20 return ret; From nobody Sat May 2 09:01:00 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 5D55DC43334 for ; Fri, 3 Jun 2022 18:02:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346119AbiFCSB5 (ORCPT ); Fri, 3 Jun 2022 14:01:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58150 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347243AbiFCRwK (ORCPT ); Fri, 3 Jun 2022 13:52:10 -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 2FF9565B0; Fri, 3 Jun 2022 10:51:08 -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 C09C560EE9; Fri, 3 Jun 2022 17:51:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CD0F1C385A9; Fri, 3 Jun 2022 17:51:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278667; bh=DdcTsahpMA3mopHeABHUdvpDhh4i1FgDJdxIWWBmhHc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=gphYyYLtbjedEeryDiSVeIGtXqFf2Jyi/7oA3Bk9ljne8tttOjOw1R4je7C4seUdF 4Mw3CHsZlyQ6p7GYZ4aXlrIYQqu60RWo+xz796qG9BAW7swYts1MKqmc+VSbL9Dj8L au/RVVUhhdpEb7JuKMXdi9eaV2qIrE0nm3D53E9E= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Dave Hansen , Reinette Chatre , Jarkko Sakkinen , Haitao Huang Subject: [PATCH 5.15 54/66] x86/sgx: Ensure no data in PCMD page after truncate Date: Fri, 3 Jun 2022 19:43:34 +0200 Message-Id: <20220603173822.222435530@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Reinette Chatre commit e3a3bbe3e99de73043a1d32d36cf4d211dc58c7e upstream. A PCMD (Paging Crypto MetaData) page contains the PCMD structures of enclave pages that have been encrypted and moved to the shmem backing store. When all enclave pages sharing a PCMD page are loaded in the enclave, there is no need for the PCMD page and it can be truncated from the backing store. A few issues appeared around the truncation of PCMD pages. The known issues have been addressed but the PCMD handling code could be made more robust by loudly complaining if any new issue appears in this area. Add a check that will complain with a warning if the PCMD page is not actually empty after it has been truncated. There should never be data in the PCMD page at this point since it is was just checked to be empty and truncated with enclave mutex held and is updated with the enclave mutex held. Suggested-by: Dave Hansen Signed-off-by: Reinette Chatre Signed-off-by: Dave Hansen Reviewed-by: Jarkko Sakkinen Tested-by: Haitao Huang Link: https://lkml.kernel.org/r/6495120fed43fafc1496d09dd23df922b9a32709.16= 52389823.git.reinette.chatre@intel.com Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Sudip Mukherjee --- arch/x86/kernel/cpu/sgx/encl.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) --- a/arch/x86/kernel/cpu/sgx/encl.c +++ b/arch/x86/kernel/cpu/sgx/encl.c @@ -187,12 +187,20 @@ static int __sgx_encl_eldu(struct sgx_en kunmap_atomic(pcmd_page); kunmap_atomic((void *)(unsigned long)pginfo.contents); =20 + get_page(b.pcmd); sgx_encl_put_backing(&b); =20 sgx_encl_truncate_backing_page(encl, page_index); =20 - if (pcmd_page_empty && !reclaimer_writing_to_pcmd(encl, pcmd_first_page)) + if (pcmd_page_empty && !reclaimer_writing_to_pcmd(encl, pcmd_first_page))= { sgx_encl_truncate_backing_page(encl, PFN_DOWN(page_pcmd_off)); + pcmd_page =3D kmap_atomic(b.pcmd); + if (memchr_inv(pcmd_page, 0, PAGE_SIZE)) + pr_warn("PCMD page not empty after truncate.\n"); + kunmap_atomic(pcmd_page); + } + + put_page(b.pcmd); =20 return ret; } From nobody Sat May 2 09:01:00 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 620F4CCA47C for ; Fri, 3 Jun 2022 18:02:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346260AbiFCSC3 (ORCPT ); Fri, 3 Jun 2022 14:02:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58152 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347244AbiFCRwK (ORCPT ); Fri, 3 Jun 2022 13:52:10 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AE14C6447; Fri, 3 Jun 2022 10:51:12 -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 60D72B82419; Fri, 3 Jun 2022 17:51:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 95C12C385A9; Fri, 3 Jun 2022 17:51:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278670; bh=Cd2X9X9D1pUtLT7Y22U/EmbcPT8vW5ZoQ885p5Z6CdU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=IL56xaMX4vBATDXb5YNy7SfNGubanyD8zImDwk30NWqzuBe0gwcsokPQM5QRFqT3U gB1dS4/IsVPMyjvydHozwgLQXdTKvnPk87dPMauS9J7kaEYEKBEw84F1lVMHbS/m4h Q6bMJ6wS3ruoMlKspwCzswCRx+T3WZ1UBcUXqjpU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Bryan ODonoghue , Jacopo Mondi , Daniele Alessandrelli , Sakari Ailus , Mauro Carvalho Chehab Subject: [PATCH 5.15 55/66] media: i2c: imx412: Fix reset GPIO polarity Date: Fri, 3 Jun 2022 19:43:35 +0200 Message-Id: <20220603173822.250099138@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Bryan O'Donoghue commit bb25f071fc92d3d227178a45853347c7b3b45a6b upstream. The imx412/imx577 sensor has a reset line that is active low not active high. Currently the logic for this is inverted. The right way to define the reset line is to declare it active low in the DTS and invert the logic currently contained in the driver. The DTS should represent the hardware does i.e. reset is active low. So: + reset-gpios =3D <&tlmm 78 GPIO_ACTIVE_LOW>; not: - reset-gpios =3D <&tlmm 78 GPIO_ACTIVE_HIGH>; I was a bit reticent about changing this logic since I thought it might negatively impact @intel.com users. Googling a bit though I believe this sensor is used on "Keem Bay" which is clearly a DTS based system and is not upstream yet. Fixes: 9214e86c0cc1 ("media: i2c: Add imx412 camera sensor driver") Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue Reviewed-by: Jacopo Mondi Reviewed-by: Daniele Alessandrelli Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Sudip Mukherjee --- drivers/media/i2c/imx412.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/drivers/media/i2c/imx412.c +++ b/drivers/media/i2c/imx412.c @@ -1011,7 +1011,7 @@ static int imx412_power_on(struct device struct imx412 *imx412 =3D to_imx412(sd); int ret; =20 - gpiod_set_value_cansleep(imx412->reset_gpio, 1); + gpiod_set_value_cansleep(imx412->reset_gpio, 0); =20 ret =3D clk_prepare_enable(imx412->inclk); if (ret) { @@ -1024,7 +1024,7 @@ static int imx412_power_on(struct device return 0; =20 error_reset: - gpiod_set_value_cansleep(imx412->reset_gpio, 0); + gpiod_set_value_cansleep(imx412->reset_gpio, 1); =20 return ret; } @@ -1040,7 +1040,7 @@ static int imx412_power_off(struct devic struct v4l2_subdev *sd =3D dev_get_drvdata(dev); struct imx412 *imx412 =3D to_imx412(sd); =20 - gpiod_set_value_cansleep(imx412->reset_gpio, 0); + gpiod_set_value_cansleep(imx412->reset_gpio, 1); =20 clk_disable_unprepare(imx412->inclk); From nobody Sat May 2 09:01:00 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 D4DEFC43334 for ; Fri, 3 Jun 2022 18:02:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245070AbiFCSCQ (ORCPT ); Fri, 3 Jun 2022 14:02:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58234 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347246AbiFCRwK (ORCPT ); Fri, 3 Jun 2022 13:52:10 -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 0326365C4; Fri, 3 Jun 2022 10:51:14 -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 9444560F38; Fri, 3 Jun 2022 17:51:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8B8DEC385A9; Fri, 3 Jun 2022 17:51:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278673; bh=1dDCelCnd3TDU/oKMdf68Nki42Ch/uDP9y6NwwQdRnE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=hbDVJ2y3Vv8j+hX78abjryF9jRFC3347OqV++vVj9yJ6X+XVyDfev2Ur0y+H2ziTq F047OeifHAwDYIGKBdZBad1sx3I2YmU37rDZAoOKTmtIQnBUU1PBgzRdmANUo1JsyJ NUhkE2nmFH0p3Fbe8P9npCdXzRBeByOKnoUt51lM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Bryan ODonoghue , Jacopo Mondi , Daniele Alessandrelli , Sakari Ailus , Mauro Carvalho Chehab Subject: [PATCH 5.15 56/66] media: i2c: imx412: Fix power_off ordering Date: Fri, 3 Jun 2022 19:43:36 +0200 Message-Id: <20220603173822.277793913@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Bryan O'Donoghue commit 9a199694c6a1519522ec73a4571f68abe9f13d5d upstream. The enable path does - gpio - clock The disable path does - gpio - clock Fix the order on the power-off path so that power-off and power-on have the same ordering for clock and gpio. Fixes: 9214e86c0cc1 ("media: i2c: Add imx412 camera sensor driver") Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue Reviewed-by: Jacopo Mondi Reviewed-by: Daniele Alessandrelli Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Sudip Mukherjee --- drivers/media/i2c/imx412.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/media/i2c/imx412.c +++ b/drivers/media/i2c/imx412.c @@ -1040,10 +1040,10 @@ static int imx412_power_off(struct devic struct v4l2_subdev *sd =3D dev_get_drvdata(dev); struct imx412 *imx412 =3D to_imx412(sd); =20 - gpiod_set_value_cansleep(imx412->reset_gpio, 1); - clk_disable_unprepare(imx412->inclk); =20 + gpiod_set_value_cansleep(imx412->reset_gpio, 1); + return 0; } From nobody Sat May 2 09:01:00 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 B7109C433EF for ; Fri, 3 Jun 2022 18:03:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346160AbiFCSDV (ORCPT ); Fri, 3 Jun 2022 14:03:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57872 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347253AbiFCRwK (ORCPT ); Fri, 3 Jun 2022 13:52:10 -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 C4F4565C8; Fri, 3 Jun 2022 10:51:16 -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 61899611F3; Fri, 3 Jun 2022 17:51:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 50F29C385A9; Fri, 3 Jun 2022 17:51:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278675; bh=yyrGhqI8IVeC53hKFu4TYqVuzOZWCA2X3vdF+q2ZsDc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=W1EH13+Z0fcc4XhTWOHTL50ChRHZwSn1Jy8Zl9M6ogVPYsOQ68wBYcLytUP6HZQQS 4I03VzP+atPuXRocRTRNmTjT7U8pzGkGplmA2Z7aZHJ0tZP1NvSweRKnujV8d7JJXk Q3wyFkQPe373Fz5fP3rXQ+l3iv7Vi7p4fc6pBd1E= 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.15 57/66] tpm: Fix buffer access in tpm2_get_tpm_pt() Date: Fri, 3 Jun 2022 19:43:37 +0200 Message-Id: <20220603173822.306766090@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos 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 @@ -400,7 +400,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 Sat May 2 09:01:00 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 5AF2EC433EF for ; Fri, 3 Jun 2022 18:04:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346363AbiFCSET (ORCPT ); Fri, 3 Jun 2022 14:04:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58244 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347256AbiFCRwK (ORCPT ); Fri, 3 Jun 2022 13:52:10 -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 E40FAA469; Fri, 3 Jun 2022 10:51: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 823B760EE9; Fri, 3 Jun 2022 17:51:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 950EAC385A9; Fri, 3 Jun 2022 17:51:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278679; bh=x5kV3Z+YxJqaxbkJ5fOTbYmq3aXHfxYboSUuniNqq7c=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=rbOzVWFVStBCbI440evV/eWVd7vbH9ek2tT3r8ffF7CYl4f6r6t4EkigQxNpQWH37 jS1grldjbV7UQLvg7H2fKt1ETFCYI51818bwCoMMjuorDCH33+W0XYfhOz1L++u9ga bgUg+GM1KaHXaEy9t6726P5ukCFwiUgKhbGHY1wA= 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.15 58/66] tpm: ibmvtpm: Correct the return value in tpm_ibmvtpm_probe() Date: Fri, 3 Jun 2022 19:43:38 +0200 Message-Id: <20220603173822.334457186@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos 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 @@ -681,6 +681,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 Sat May 2 09:01:00 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 D396FC433EF for ; Fri, 3 Jun 2022 18:04:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346568AbiFCSEa (ORCPT ); Fri, 3 Jun 2022 14:04:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58298 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347251AbiFCRwK (ORCPT ); Fri, 3 Jun 2022 13:52:10 -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 995A3A477; Fri, 3 Jun 2022 10:51: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 ams.source.kernel.org (Postfix) with ESMTPS id 58154B8241E; Fri, 3 Jun 2022 17:51:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8E199C385A9; Fri, 3 Jun 2022 17:51:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278682; bh=QlLcae46l2AfW86cySqI/MBnPdglzOpdGmoZnLvCjQI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=MoqE8umoe7c8RdOHZAfVHg+1MCArpasHrU04j72/5g5cV0q4KPlR7twWepJTSt2W5 YeGluFcwHBcD1fGKaeGC+Poi/0SubKnKHtZ6KerXF/hr4V2gnuC+AtijFYitkQh7/K j4kYAkJdQrjcjGbJIoLDn98AkJxgp6Fa2VP/iXB4= 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.15 59/66] docs: submitting-patches: Fix crossref to The canonical patch format Date: Fri, 3 Jun 2022 19:43:39 +0200 Message-Id: <20220603173822.362514851@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos 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 @@ -72,7 +72,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 Sat May 2 09:01:00 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 0087AC43334 for ; Fri, 3 Jun 2022 18:02:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346325AbiFCSCu (ORCPT ); Fri, 3 Jun 2022 14:02:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58242 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347258AbiFCRwK (ORCPT ); Fri, 3 Jun 2022 13:52:10 -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 1543EA478; Fri, 3 Jun 2022 10:51:26 -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 A552760EE9; Fri, 3 Jun 2022 17:51:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A6EF0C385B8; Fri, 3 Jun 2022 17:51:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278685; bh=iVhxgBee0090K+JMRIMNDvagDEz2fQsj8dQrdToLUgg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=O4VfgkhrELevKR3zonCy0ElKPG/UkSEOLPh2X1JcNtEqX0BY1HvkVL5oeUTqNXbqW YCuBJMG4UVSIMMsi6vVlmuWMvXb7UOPfXC8JCPSxwMfjD7/0POdyDtuBcTiNkS9+oW Ny+t4ON1ArcqxC5rHpYik3GybWY21jfQqSnejof4= 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.15 60/66] NFS: Memory allocation failures are not server fatal errors Date: Fri, 3 Jun 2022 19:43:40 +0200 Message-Id: <20220603173822.391111019@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Sudip Mukherjee --- fs/nfs/internal.h | 1 + 1 file changed, 1 insertion(+) --- a/fs/nfs/internal.h +++ b/fs/nfs/internal.h @@ -834,6 +834,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 Sat May 2 09:01:00 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 DD072C43334 for ; Fri, 3 Jun 2022 18:03:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345023AbiFCSDO (ORCPT ); Fri, 3 Jun 2022 14:03:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58038 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347252AbiFCRwK (ORCPT ); Fri, 3 Jun 2022 13:52:10 -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 9351E10C6; Fri, 3 Jun 2022 10:51: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 5544BB82419; Fri, 3 Jun 2022 17:51:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B189EC385A9; Fri, 3 Jun 2022 17:51:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278688; bh=mB+SpYiPRzPhBV13Cg9C1SHpOxcek38O6FyT0T08+1c=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=CsfyqCh0Th0z3gfOMqIyXkQhBEUksFbQ7VnHDqaOARIYUtmcgfr2efiNf8+4edHFx 3fZAAdbmUtTjGZCNyGGkf993xFMkAc/BXQieYhnIHymQDeaZSOCkYTm4EM0cObCw5c STvitLqlB1YDZrnROsqlplDWn2Qmp9WSi7qVwelQ= 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.15 61/66] NFSD: Fix possible sleep during nfsd4_release_lockowner() Date: Fri, 3 Jun 2022 19:43:41 +0200 Message-Id: <20220603173822.419864488@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos 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 @@ -7299,16 +7299,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 Sat May 2 09:01:00 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 3D769C43334 for ; Fri, 3 Jun 2022 18:04:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346576AbiFCSEg (ORCPT ); Fri, 3 Jun 2022 14:04:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58408 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347259AbiFCRwK (ORCPT ); Fri, 3 Jun 2022 13:52:10 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B8D5C1022; Fri, 3 Jun 2022 10:51:33 -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 6FF22B823B0; Fri, 3 Jun 2022 17:51:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C244BC385A9; Fri, 3 Jun 2022 17:51:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278691; bh=MsuXO/3SvW5BQwKSfKAvfQ7HGwMvLsatlWhEzgsRt+M=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Mm7bjO6JHLpLH0ra30Ohra3hT0++ckCg9GLkOpuTywp2U0bYr198Q+0Jra6F4/MvI KSvvYRntl9Dux4+0M5on2pNs/fjzLxpidpmr3rxT4VQlIbAbxAx/eMtAXNj+sGUKf0 /wmKH9nv2FWMvgRoH0xFjaoEM9JI+//i1ONBvtyw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Yuntao Wang , Alexei Starovoitov Subject: [PATCH 5.15 62/66] bpf: Fix potential array overflow in bpf_trampoline_get_progs() Date: Fri, 3 Jun 2022 19:43:42 +0200 Message-Id: <20220603173822.447929441@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Yuntao Wang commit a2aa95b71c9bbec793b5c5fa50f0a80d882b3e8d upstream. The cnt value in the 'cnt >=3D BPF_MAX_TRAMP_PROGS' check does not include BPF_TRAMP_MODIFY_RETURN bpf programs, so the number of the attached BPF_TRAMP_MODIFY_RETURN bpf programs in a trampoline can exceed BPF_MAX_TRAMP_PROGS. When this happens, the assignment '*progs++ =3D aux->prog' in bpf_trampoline_get_progs() will cause progs array overflow as the progs field in the bpf_tramp_progs struct can only hold at most BPF_MAX_TRAMP_PROGS bpf programs. Fixes: 88fd9e5352fe ("bpf: Refactor trampoline update code") Signed-off-by: Yuntao Wang Link: https://lore.kernel.org/r/20220430130803.210624-1-ytcoode@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Sudip Mukherjee --- kernel/bpf/trampoline.c | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) --- a/kernel/bpf/trampoline.c +++ b/kernel/bpf/trampoline.c @@ -414,7 +414,7 @@ int bpf_trampoline_link_prog(struct bpf_ { enum bpf_tramp_prog_type kind; int err =3D 0; - int cnt; + int cnt =3D 0, i; =20 kind =3D bpf_attach_type_to_tramp(prog); mutex_lock(&tr->mutex); @@ -425,7 +425,10 @@ int bpf_trampoline_link_prog(struct bpf_ err =3D -EBUSY; goto out; } - cnt =3D tr->progs_cnt[BPF_TRAMP_FENTRY] + tr->progs_cnt[BPF_TRAMP_FEXIT]; + + for (i =3D 0; i < BPF_TRAMP_MAX; i++) + cnt +=3D tr->progs_cnt[i]; + if (kind =3D=3D BPF_TRAMP_REPLACE) { /* Cannot attach extension if fentry/fexit are in use. */ if (cnt) { @@ -503,16 +506,19 @@ out: =20 void bpf_trampoline_put(struct bpf_trampoline *tr) { + int i; + if (!tr) return; mutex_lock(&trampoline_mutex); if (!refcount_dec_and_test(&tr->refcnt)) goto out; WARN_ON_ONCE(mutex_is_locked(&tr->mutex)); - if (WARN_ON_ONCE(!hlist_empty(&tr->progs_hlist[BPF_TRAMP_FENTRY]))) - goto out; - if (WARN_ON_ONCE(!hlist_empty(&tr->progs_hlist[BPF_TRAMP_FEXIT]))) - goto out; + + for (i =3D 0; i < BPF_TRAMP_MAX; i++) + if (WARN_ON_ONCE(!hlist_empty(&tr->progs_hlist[i]))) + goto out; + /* This code will be executed even when the last bpf_tramp_image * is alive. All progs are detached from the trampoline and the * trampoline image is patched with jmp into epilogue to skip From nobody Sat May 2 09:01:00 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 A11B7C43334 for ; Fri, 3 Jun 2022 18:02:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245160AbiFCSCj (ORCPT ); Fri, 3 Jun 2022 14:02:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58232 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347257AbiFCRwK (ORCPT ); Fri, 3 Jun 2022 13:52:10 -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 C19F3B1FB; Fri, 3 Jun 2022 10:51: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 849C3B823B0; Fri, 3 Jun 2022 17:51:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E36A1C385A9; Fri, 3 Jun 2022 17:51:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278694; bh=szD02mP4YgUH+qF/S0nQ5Cv3/j6NNflP7nUmREGze1E=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=sJMuBc6U1U39ozEuEkFlIAtZNSTNAApYouot8GoKzMNRIy7hJHuFt/ekQn05Kvb/T ZVefy2TZqRAtY6yusR6o8AlhhsjW0FKgvkREkcV47oDxq5ukjLYvdm6hj+uo/duGVy bRFJkoYL6HIPrVRqNnirFPl1IuDNmYCoJHFlSNkE= 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.15 63/66] bpf: Enlarge offset check value to INT_MAX in bpf_skb_{load,store}_bytes Date: Fri, 3 Jun 2022 19:43:43 +0200 Message-Id: <20220603173822.476005225@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos 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 @@ -1688,7 +1688,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; @@ -1723,7 +1723,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); From nobody Sat May 2 09:01:00 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 19690C433EF for ; Fri, 3 Jun 2022 18:02:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345867AbiFCSCz (ORCPT ); Fri, 3 Jun 2022 14:02:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57860 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347260AbiFCRwK (ORCPT ); Fri, 3 Jun 2022 13:52:10 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6387FB4B1; Fri, 3 Jun 2022 10:51: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 130F7B823B0; Fri, 3 Jun 2022 17:51:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 35EDEC385A9; Fri, 3 Jun 2022 17:51:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278700; bh=XJM0lwkShHlP+CUihjc1TOUi9hlvEuV01oCFVztSbGk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=wMXfogTYIEkrBIpQOQFajR/hpTtNIvx82JLjha8m7m6dz48RJU/pV+FRJ2OE6s+Gs ol9WwoI0N+F17JmfoEZ8stpK/BU27vX1QUZCgyfFdPYR072r44j2dRLWVHGyqNPtQU FVr/15rxET1h+7qGoXM2PXHSZqlqz6D7YeEFCCBc= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Yuntao Wang , Daniel Borkmann Subject: [PATCH 5.15 64/66] bpf: Fix excessive memory allocation in stack_map_alloc() Date: Fri, 3 Jun 2022 19:43:44 +0200 Message-Id: <20220603173822.504836401@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Yuntao Wang commit b45043192b3e481304062938a6561da2ceea46a6 upstream. The 'n_buckets * (value_size + sizeof(struct stack_map_bucket))' part of the allocated memory for 'smap' is never used after the memlock accounting was removed, thus get rid of it. [ Note, Daniel: Commit b936ca643ade ("bpf: rework memlock-based memory accounting for maps") moved `cost +=3D n_buckets * (value_size + sizeof(struct stack_map_bucket))` up and therefore before the bpf_map_area_alloc() allocation, sigh. In a lat= er step commit c85d69135a91 ("bpf: move memory size checks to bpf_map_charge_i= nit()"), and the overflow checks of `cost >=3D U32_MAX - PAGE_SIZE` moved into bpf_map_charge_init(). And then 370868107bf6 ("bpf: Eliminate rlimit-based memory accounting for stackmap maps") finally removed the bpf_map_charge_in= it(). Anyway, the original code did the allocation same way as /after/ this fix. ] Fixes: b936ca643ade ("bpf: rework memlock-based memory accounting for maps") Signed-off-by: Yuntao Wang Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20220407130423.798386-1-ytcoode@gmail.com Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Sudip Mukherjee --- kernel/bpf/stackmap.c | 1 - 1 file changed, 1 deletion(-) --- a/kernel/bpf/stackmap.c +++ b/kernel/bpf/stackmap.c @@ -119,7 +119,6 @@ static struct bpf_map *stack_map_alloc(u return ERR_PTR(-E2BIG); =20 cost =3D n_buckets * sizeof(struct stack_map_bucket *) + sizeof(*smap); - cost +=3D n_buckets * (value_size + sizeof(struct stack_map_bucket)); smap =3D bpf_map_area_alloc(cost, bpf_map_attr_numa_node(attr)); if (!smap) return ERR_PTR(-ENOMEM); From nobody Sat May 2 09:01:00 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 21C1AC433EF for ; Fri, 3 Jun 2022 18:02:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346294AbiFCSCo (ORCPT ); Fri, 3 Jun 2022 14:02:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58162 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347262AbiFCRwK (ORCPT ); Fri, 3 Jun 2022 13:52:10 -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 7AF16E3F; Fri, 3 Jun 2022 10:51:46 -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 3F326B82189; Fri, 3 Jun 2022 17:51:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 91C88C385A9; Fri, 3 Jun 2022 17:51:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278704; bh=r/EVGuixxhLyn4hbt87fKDBBAPp8TGSvK5WszfHhZ5Y=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=itooazSEeiYbbUDMiRc5f0WingTZUOTxIfSuk8nCAwVDF3QFz6nALfi6+pGbopemd nsu+1rddJhplQwvmtLA8qPYQ3OR6qJREV/83xXrxeDCY/GC8weZzyln6UBfFjf21Aa MK0Wuf+G6pqmt9/oCj7Ekiwxr8YTEc4KaEvwth0A= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Kumar Kartikeya Dwivedi , Alexei Starovoitov Subject: [PATCH 5.15 65/66] bpf: Reject writes for PTR_TO_MAP_KEY in check_helper_mem_access Date: Fri, 3 Jun 2022 19:43:45 +0200 Message-Id: <20220603173822.532138272@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Kumar Kartikeya Dwivedi commit 7b3552d3f9f6897851fc453b5131a967167e43c2 upstream. It is not permitted to write to PTR_TO_MAP_KEY, but the current code in check_helper_mem_access would allow for it, reject this case as well, as helpers taking ARG_PTR_TO_UNINIT_MEM also take PTR_TO_MAP_KEY. Fixes: 69c087ba6225 ("bpf: Add bpf_for_each_map_elem() helper") Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20220319080827.73251-4-memxor@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Sudip Mukherjee --- kernel/bpf/verifier.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -4587,6 +4587,11 @@ static int check_helper_mem_access(struc return check_packet_access(env, regno, reg->off, access_size, zero_size_allowed); case PTR_TO_MAP_KEY: + if (meta && meta->raw_mode) { + verbose(env, "R%d cannot write into %s\n", regno, + reg_type_str(env, reg->type)); + return -EACCES; + } return check_mem_region_access(env, regno, reg->off, access_size, reg->map_ptr->key_size, false); case PTR_TO_MAP_VALUE: From nobody Sat May 2 09:01:00 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 1F2FBC43334 for ; Fri, 3 Jun 2022 18:03:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346467AbiFCSDG (ORCPT ); Fri, 3 Jun 2022 14:03:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58142 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347263AbiFCRwK (ORCPT ); Fri, 3 Jun 2022 13:52:10 -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 1AD6AE53; Fri, 3 Jun 2022 10:51: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 AC64B60F7F; Fri, 3 Jun 2022 17:51:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A28FAC385A9; Fri, 3 Jun 2022 17:51:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278707; bh=0K5voZzLyc+xuScdTQ/pYb/ZRAHzPncbwaYY8Xc9DiI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=KYyrxSjC3lqspTKNZXq5mraVMaRLO4ZTf57TQUfdaojcrr53n38IgJTVdm3wczcMo r2jAb2Knzi+JjLyIqF6OliGH7YYpd9A18JvFDNgudnpCGcCSx1nRhJMWSFkkFfVHX2 JlyF5XoFxmY/YvyHYNPyUXDFCU7GvB2wh00cpNzA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Hao Luo , Kumar Kartikeya Dwivedi , Alexei Starovoitov Subject: [PATCH 5.15 66/66] bpf: Check PTR_TO_MEM | MEM_RDONLY in check_helper_mem_access Date: Fri, 3 Jun 2022 19:43:46 +0200 Message-Id: <20220603173822.559821958@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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: Kumar Kartikeya Dwivedi commit 97e6d7dab1ca4648821c790a2b7913d6d5d549db upstream. The commit being fixed was aiming to disallow users from incorrectly obtaining writable pointer to memory that is only meant to be read. This is enforced now using a MEM_RDONLY flag. For instance, in case of global percpu variables, when the BTF type is not struct (e.g. bpf_prog_active), the verifier marks register type as PTR_TO_MEM | MEM_RDONLY from bpf_this_cpu_ptr or bpf_per_cpu_ptr helpers. However, when passing such pointer to kfunc, global funcs, or BPF helpers, in check_helper_mem_access, there is no expectation MEM_RDONLY flag will be set, hence it is checked as pointer to writable memory. Later, verifier sets up argument type of global func as PTR_TO_MEM | PTR_MAYBE_NULL, so user can use a global func to get around the limitations imposed by this flag. This check will also cover global non-percpu variables that may be introduced in kernel BTF in future. Also, we update the log message for PTR_TO_BUF case to be similar to PTR_TO_MEM case, so that the reason for error is clear to user. Fixes: 34d3a78c681e ("bpf: Make per_cpu_ptr return rdonly PTR_TO_MEM.") Reviewed-by: Hao Luo Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20220319080827.73251-3-memxor@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Sudip Mukherjee --- kernel/bpf/verifier.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -4602,13 +4602,23 @@ static int check_helper_mem_access(struc return check_map_access(env, regno, reg->off, access_size, zero_size_allowed); case PTR_TO_MEM: + if (type_is_rdonly_mem(reg->type)) { + if (meta && meta->raw_mode) { + verbose(env, "R%d cannot write into %s\n", regno, + reg_type_str(env, reg->type)); + return -EACCES; + } + } return check_mem_region_access(env, regno, reg->off, access_size, reg->mem_size, zero_size_allowed); case PTR_TO_BUF: if (type_is_rdonly_mem(reg->type)) { - if (meta && meta->raw_mode) + if (meta && meta->raw_mode) { + verbose(env, "R%d cannot write into %s\n", regno, + reg_type_str(env, reg->type)); return -EACCES; + } =20 buf_info =3D "rdonly"; max_access =3D &env->prog->aux->max_rdonly_access;