From nobody Tue Apr 28 06:30:16 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 A852CC43334 for ; Fri, 3 Jun 2022 18:17:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345134AbiFCSRg (ORCPT ); Fri, 3 Jun 2022 14:17:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37854 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347374AbiFCSF5 (ORCPT ); Fri, 3 Jun 2022 14:05:57 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DF61A5BD03; Fri, 3 Jun 2022 10:58: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 dfw.source.kernel.org (Postfix) with ESMTPS id 593C8615FF; Fri, 3 Jun 2022 17:57:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 48898C385A9; Fri, 3 Jun 2022 17:57:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279070; bh=4ltGxpT2RJ3O0cMXesB42/3fugT5SM7Txn12IgNpxEM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=w6iAj2ZdRAGfvkpRmNaM3hkpQfL4EEuLZYOrI5FOa54qxH03Mzz93j1SsGpHObQ4Z gcBsPJHh8ls2fHT0Ryf3OLT6JONcsA9mtIQkAPnvk4r3llSjf7uTj0tjiKltcT2rsZ dPFCM3ifDF8BLhePUUzkTPh3AMRTv2tXXZpDqk0g= 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.18 01/67] netfilter: nf_tables: disallow non-stateful expression in sets earlier Date: Fri, 3 Jun 2022 19:43:02 +0200 Message-Id: <20220603173820.776292973@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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: 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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- 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 @@ -2873,27 +2873,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_ACCOUNT); 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 @@ -5413,9 +5417,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 Tue Apr 28 06:30:16 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 8A658CCA485 for ; Fri, 3 Jun 2022 18:16:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347598AbiFCSPw (ORCPT ); Fri, 3 Jun 2022 14:15:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47684 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346302AbiFCSAK (ORCPT ); Fri, 3 Jun 2022 14:00: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 70DB254186; Fri, 3 Jun 2022 10:56: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 dfw.source.kernel.org (Postfix) with ESMTPS id 10A1D60F3B; Fri, 3 Jun 2022 17:56:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0BFBBC385B8; Fri, 3 Jun 2022 17:56:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278966; bh=K6tYsH8bSgs3PfSjUaakxOh0TLf3zeJAhtERYiKfyYg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=2ONCK6YXqUyczCVQUi1hmlH61KKhw3A/Bf8Wq88aYvJzPn4+DdwFB4gFIzQ5hhJ0L ZWcuVRJ5dfAwV9Om4AEplJyjvtd4xEdZFYoUnKz8BtG3+k2TAXDW0zR7ZqspMQBCEF J0Y6chVoBdCOAcFYWf+zYyXii2T1oHwA1L7O2If4= 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.18 02/67] i2c: ismt: prevent memory corruption in ismt_access() Date: Fri, 3 Jun 2022 19:43:03 +0200 Message-Id: <20220603173820.803679942@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- 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 Tue Apr 28 06:30:16 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 BD763CCA48F for ; Fri, 3 Jun 2022 18:16:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347196AbiFCSPe (ORCPT ); Fri, 3 Jun 2022 14:15:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51060 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346597AbiFCSA0 (ORCPT ); Fri, 3 Jun 2022 14:00:26 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E9F7E59322; Fri, 3 Jun 2022 10:56:41 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id C26CD615DE; Fri, 3 Jun 2022 17:56:40 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B71F8C385A9; Fri, 3 Jun 2022 17:56:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279000; bh=YWUFwpqGOmVXmiw7aGglaLnf0+DjQhPIXhsvaJzq574=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=FC//Ktoeldo3W9M4U8YakPmiID9VdFWdFRNoTEKmmK6yfpxFnLuv3jKS8ZFkthkLe A3xxsQES4wsunO3gWuKp99lc3e0mX4hyK4JpAUkw8YnJB/yWNWbTe72xdIlTNfStLN tfYHcjBkoxgeMrnmk8YRKT5fMdwOcCZN6flfQDfk= 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.18 03/67] assoc_array: Fix BUG_ON during garbage collect Date: Fri, 3 Jun 2022 19:43:04 +0200 Message-Id: <20220603173820.831718616@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- lib/assoc_array.c | 8 ++++++++ 1 file changed, 8 insertions(+) --- a/lib/assoc_array.c +++ b/lib/assoc_array.c @@ -1461,6 +1461,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__); @@ -1536,6 +1537,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 @@ -1553,6 +1555,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; @@ -1602,9 +1605,14 @@ continue_node: pr_devel("[%d] retain node %lu/%d [nx %d]\n", slot, child->nr_leaves_on_branch, nr_free + 1, next_slot); + retained =3D true; } } =20 + if (retained && new_n->nr_leaves_on_branch <=3D ASSOC_ARRAY_FAN_OUT) { + pr_devel("internal nodes remain despite enough space, retrying\n"); + goto retry_compress; + } pr_devel("after: %lu\n", new_n->nr_leaves_on_branch); =20 nr_leaves_on_tree =3D new_n->nr_leaves_on_branch; From nobody Tue Apr 28 06:30:16 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 BDA96CCA47E for ; Fri, 3 Jun 2022 18:21:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347683AbiFCSVB (ORCPT ); Fri, 3 Jun 2022 14:21:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47106 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347033AbiFCSFf (ORCPT ); Fri, 3 Jun 2022 14:05:35 -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 8F4B05A59B; Fri, 3 Jun 2022 10:58: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 1E525B82436; Fri, 3 Jun 2022 17:57:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 625DCC385A9; Fri, 3 Jun 2022 17:57:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279033; bh=3UL3x2f2WyP8DSvLWX62I8m/JkJuzbJBFvpyHQs11YU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Zz3hAYvK6zI/+slKwbrZHkT+uTVJTqlDQrK3RZcglhbev6fif0gLGijjuKRoYUQ7L EltNwT6FZ4bakOpJ24yzBZndEC/t59qUx35zs9dkPKFBhHzaosBTcxydhNBc0ryVgd aF855MD7kHtZ92taLw4stzZ5J2k7MDbz6Xx+r5HE= 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.18 04/67] pipe: make poll_usage boolean and annotate its access Date: Fri, 3 Jun 2022 19:43:05 +0200 Message-Id: <20220603173820.860166986@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- 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 @@ -653,7 +653,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 Tue Apr 28 06:30:16 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 ACDEDCCA473 for ; Fri, 3 Jun 2022 18:21:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347658AbiFCSU4 (ORCPT ); Fri, 3 Jun 2022 14:20:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55574 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347203AbiFCSFn (ORCPT ); Fri, 3 Jun 2022 14:05:43 -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 178285AA47; Fri, 3 Jun 2022 10:58:39 -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 AA3D261607; Fri, 3 Jun 2022 17:57:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9FE8CC385A9; Fri, 3 Jun 2022 17:57:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279052; bh=r07Ht/o8tyr7rzBej9Sx5OpKHymm6LYC2S7Uzqujyko=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=bspohtLeVgr7Jz27/5hbmzRyaQa5GYMaa8JpjtcrMSJrtMIKnLumHL0yCvI/W2lC5 oonhEjBUGbCDBsslF9JRHTyj1zjesPIJ7ZySqNQPqws4AA23QbIJ4PbbiPn9GtF1RA 2rZliusndY1F76vLrnuG6kdxe4E9Syxgib3hUhqg= 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.18 05/67] pipe: Fix missing lock in pipe_resize_ring() Date: Fri, 3 Jun 2022 19:43:06 +0200 Message-Id: <20220603173820.888231000@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- fs/pipe.c | 31 ++++++++++++++++++------------- 1 file changed, 18 insertions(+), 13 deletions(-) --- a/fs/pipe.c +++ b/fs/pipe.c @@ -1245,30 +1245,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. @@ -1300,6 +1303,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 Tue Apr 28 06:30:16 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 DE76FC433EF for ; Fri, 3 Jun 2022 18:19:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347091AbiFCSTX (ORCPT ); Fri, 3 Jun 2022 14:19:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44990 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346967AbiFCSFc (ORCPT ); Fri, 3 Jun 2022 14:05:32 -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 4DC705A2F2; Fri, 3 Jun 2022 10:58: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 A5DA3615C8; Fri, 3 Jun 2022 17:57:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A721DC385A9; Fri, 3 Jun 2022 17:57:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279055; bh=0Hxm7VfHN0KwafIDjex29HGSMuWAetdQhX0hc5y9oEE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=V9iRsgKhHgLkhf+0SZEzfYibmLNiv8fC6uaKUxySttsL+PyHshgVanOYcdLcxqth2 nd5AHWPRWuUNbQ0O5bZZa9X3MFmIp/ilgkE6PQ2RWjf4YpFQlTa/92vA7QZeJX8o6f OegFcpIkwbZnip3qiRY1mUfN70ybcamrj6hCoKv0= 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.18 06/67] net: ipa: compute proper aggregation limit Date: Fri, 3 Jun 2022 19:43:07 +0200 Message-Id: <20220603173820.916586811@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- drivers/net/ipa/ipa_endpoint.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) --- a/drivers/net/ipa/ipa_endpoint.c +++ b/drivers/net/ipa/ipa_endpoint.c @@ -130,9 +130,10 @@ static bool ipa_endpoint_data_valid_one( */ if (data->endpoint.config.aggregation) { limit +=3D SZ_1K * aggr_byte_limit_max(ipa->version); - if (buffer_size > limit) { + if (buffer_size - NET_SKB_PAD > limit) { dev_err(dev, "RX buffer size too large for aggregated RX endpoint %u (= %u > %u)\n", - data->endpoint_id, buffer_size, limit); + data->endpoint_id, + buffer_size - NET_SKB_PAD, limit); =20 return false; } @@ -739,6 +740,7 @@ static void ipa_endpoint_init_aggr(struc if (endpoint->data->aggregation) { if (!endpoint->toward_ipa) { const struct ipa_endpoint_rx_data *rx_data; + u32 buffer_size; bool close_eof; u32 limit; =20 @@ -746,7 +748,8 @@ static void ipa_endpoint_init_aggr(struc 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(rx_data->buffer_size); + buffer_size =3D rx_data->buffer_size; + limit =3D ipa_aggr_size_kb(buffer_size - NET_SKB_PAD); val |=3D aggr_byte_limit_encoded(version, limit); =20 limit =3D IPA_AGGR_TIME_LIMIT; From nobody Tue Apr 28 06:30:16 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 6E81CCCA480 for ; Fri, 3 Jun 2022 18:16:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243429AbiFCSQ4 (ORCPT ); Fri, 3 Jun 2022 14:16:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46902 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347012AbiFCSFe (ORCPT ); Fri, 3 Jun 2022 14:05:34 -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 8EA3B5A593; Fri, 3 Jun 2022 10:58:25 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id E7DA7615DE; Fri, 3 Jun 2022 17:57:38 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DD8DDC385B8; Fri, 3 Jun 2022 17:57:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279058; bh=9TzOxzYF8eQz/bXIO0PdNTDxg8YV9WqOGd1aYO4rg/k=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=OCil8AJRxSGbAiw4GlZWq5LW0wKaVaaUQEwdpuwEqWhPaNPv2W0QK8nNCxLM9eRDK YVwh23v1PR5NH/w3NZ/7wb5St16tQcNiuc/0CQpJL7rZo1RkUz+D8VzT7QVWf9GlUh UeDHUK+cqlEUMNAFvDxi39W8zvsLAgOXE8V12s9g= 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.18 07/67] drm/i915: Fix -Wstringop-overflow warning in call to intel_read_wm_latency() Date: Fri, 3 Jun 2022 19:43:08 +0200 Message-Id: <20220603173820.944138268@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- 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 @@ -2859,7 +2859,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 Tue Apr 28 06:30:16 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 EFD34CCA491 for ; Fri, 3 Jun 2022 18:16:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346133AbiFCSQv (ORCPT ); Fri, 3 Jun 2022 14:16:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36418 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347009AbiFCSFe (ORCPT ); Fri, 3 Jun 2022 14:05:34 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8F1E45A598; Fri, 3 Jun 2022 10:58:25 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id DC58561653; Fri, 3 Jun 2022 17:57:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EF672C385A9; Fri, 3 Jun 2022 17:57:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279061; bh=M2d9iS/i0OY0KVXBVPir97YtU4ReZeixnC1Ob7/0Aok=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=EiwhaCFVSa184u/qrT2jcHHejk3dpf6+ie0ivQhNF0xMfnxLlfBVOQc8BuY76zJOY g03nnXV0nMs8DbnYuVeG9vwgcuPH1kQ+x4vIHdTw986h+rcYoiATECvBp+wUSfgZpX pKqbUmTOzT6XnpE1sCcX5Z8CQiia2MulWYYMjm2A= 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.18 08/67] exfat: check if cluster num is valid Date: Fri, 3 Jun 2022 19:43:09 +0200 Message-Id: <20220603173820.972203402@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- fs/exfat/balloc.c | 8 ++++++-- fs/exfat/exfat_fs.h | 6 ++++++ fs/exfat/fatent.c | 6 ------ 3 files changed, 12 insertions(+), 8 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,12 @@ 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) +{ + return clus >=3D EXFAT_FIRST_CLUSTER && clus < sbi->num_clusters; +} + /* 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,12 +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) -{ - return clus >=3D EXFAT_FIRST_CLUSTER && clus < sbi->num_clusters; -} - int exfat_ent_get(struct super_block *sb, unsigned int loc, unsigned int *content) { From nobody Tue Apr 28 06:30:16 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 518EBCCA473 for ; Fri, 3 Jun 2022 18:17:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238830AbiFCSRb (ORCPT ); Fri, 3 Jun 2022 14:17:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44984 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347093AbiFCSFi (ORCPT ); Fri, 3 Jun 2022 14:05:38 -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 EF2885AA68; Fri, 3 Jun 2022 10:58:32 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id D7152615E5; Fri, 3 Jun 2022 17:57:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D9000C385A9; Fri, 3 Jun 2022 17:57:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279064; bh=Bkle9clltA+R6fN9FLeBxz6W1Wqn17K3e2OD2XvnkVw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=nn7E8ALkK8SifCIGqa5h0K62z6bGTSRgzKpBl4sake295wCaFgNKEkqjWsPaNkCmN /bvKOX9js0O1hyfFCWkQOSZfaXgtAzGqKonjCsWcjdxbQXLpyJa6/ujHvDZDhl1i3C AIE28f7edmBojbAN9b0905zaVn932Exrtvjg6wIo= 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.18 09/67] exfat: fix referencing wrong parent directory information after renaming Date: Fri, 3 Jun 2022 19:43:10 +0200 Message-Id: <20220603173821.000877880@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- fs/exfat/namei.c | 27 +-------------------------- 1 file changed, 1 insertion(+), 26 deletions(-) --- a/fs/exfat/namei.c +++ b/fs/exfat/namei.c @@ -1080,6 +1080,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) { @@ -1167,28 +1168,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, @@ -1219,8 +1198,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 @@ -1241,8 +1218,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); From nobody Tue Apr 28 06:30:16 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 70844CCA483 for ; Fri, 3 Jun 2022 18:21:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347496AbiFCSUe (ORCPT ); Fri, 3 Jun 2022 14:20:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44984 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347361AbiFCSF4 (ORCPT ); Fri, 3 Jun 2022 14:05:56 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0D1C85B89C; Fri, 3 Jun 2022 10:58:52 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 1135061659; Fri, 3 Jun 2022 17:57:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 04811C385A9; Fri, 3 Jun 2022 17:57:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279067; bh=/5ETmfWm2uhKWwgWPbY3yLxXWCxaJ5ZGh8hkglP8XMM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=W5KIEmeSBJjsv1LO6uA8T4Bsbwenm4h0ZJhr1PL/nglQPPBaWHETdXKCoQd5Mshod RpdGEwwptaQQcrQA4wfQ6VqK8wNuyXWsewMKpiZjIpz7IvVFa/F61YmIeHEr9xSEjz BGMHRvdJQtP7mpmuYqFR72SUpkO1QSxZJ3ksFcf0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Phil Sutter , Pablo Neira Ayuso Subject: [PATCH 5.18 10/67] netfilter: nft_limit: Clone packet limits cost value Date: Fri, 3 Jun 2022 19:43:11 +0200 Message-Id: <20220603173821.029370451@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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: Phil Sutter commit 558254b0b602b8605d7246a10cfeb584b1fcabfc upstream. When cloning a packet-based limit expression, copy the cost value as well. Otherwise the new limit is not functional anymore. Fixes: 3b9e2ea6c11bf ("netfilter: nft_limit: move stateful fields out of ex= pression data") Signed-off-by: Phil Sutter Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- net/netfilter/nft_limit.c | 2 ++ 1 file changed, 2 insertions(+) --- a/net/netfilter/nft_limit.c +++ b/net/netfilter/nft_limit.c @@ -213,6 +213,8 @@ static int nft_limit_pkts_clone(struct n struct nft_limit_priv_pkts *priv_dst =3D nft_expr_priv(dst); struct nft_limit_priv_pkts *priv_src =3D nft_expr_priv(src); =20 + priv_dst->cost =3D priv_src->cost; + return nft_limit_clone(&priv_dst->limit, &priv_src->limit); } From nobody Tue Apr 28 06:30:16 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 0C0D7C433EF for ; Fri, 3 Jun 2022 18:14:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240365AbiFCSOX (ORCPT ); Fri, 3 Jun 2022 14:14:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51212 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346326AbiFCSAM (ORCPT ); Fri, 3 Jun 2022 14:00:12 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 11980580FB; Fri, 3 Jun 2022 10:56: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 AD5A2B82189; Fri, 3 Jun 2022 17:56:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 04A3EC385A9; Fri, 3 Jun 2022 17:56:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278969; bh=aoUjbgcq58r/JunbedBzWXG5Q2u5FFyKsXE1IlujZss=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=By2NfNdrHNUfeXeQRmeokeUANEvVk1XIOwqWIhQGYnDqc0AhSEFN9AOCHk7vsS1+J PPDLkJVxiV/CUGe2zKILlTyT1Bjp3djjc1po+SIy69k6WZD5EoW23meWTZfk6YY3Z+ IA58uKwLlyf+PIUGIFG7919Q6FTapkl0YQjTaW7E= 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.18 11/67] netfilter: nf_tables: sanitize nft_set_desc_concat_parse() Date: Fri, 3 Jun 2022 19:43:12 +0200 Message-Id: <20220603173821.057219025@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- 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 @@ -4246,6 +4246,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) @@ -4255,9 +4258,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 @@ -4268,7 +4270,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) @@ -4279,6 +4282,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 Tue Apr 28 06:30:16 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 07639C43334 for ; Fri, 3 Jun 2022 18:14:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345955AbiFCSOM (ORCPT ); Fri, 3 Jun 2022 14:14:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51690 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346336AbiFCSAO (ORCPT ); Fri, 3 Jun 2022 14:00:14 -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 199E95838E; Fri, 3 Jun 2022 10:56:15 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id B8F0EB82433; Fri, 3 Jun 2022 17:56:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1659DC385A9; Fri, 3 Jun 2022 17:56:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278972; bh=VPZI7tJahhauuvn30Lcv1xk+LwkmDvyMkCVb3evQetg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=XjGD0uD4QIA/ht9jVsuPsW/muVV0pyrufNa2tiH+n/BY2KZpu4CNdIYNJ8sVfSfUF mSKogDDbqpTJXjp0f3gLaK7CgAk802JrjQUaeU6aDJBFnJo8yjHdDhSYpxfsQ3KWhu fgMdLmAjOGJSpgO4xz/m1TlKO3/4mHf9Bg+DNfRk= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Pablo Neira Ayuso Subject: [PATCH 5.18 12/67] netfilter: nf_tables: hold mutex on netns pre_exit path Date: Fri, 3 Jun 2022 19:43:13 +0200 Message-Id: <20220603173821.084953001@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- 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 @@ -9892,7 +9892,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 Tue Apr 28 06:30:16 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 BB7F6C433EF for ; Fri, 3 Jun 2022 18:14:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346326AbiFCSO2 (ORCPT ); Fri, 3 Jun 2022 14:14:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47582 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346366AbiFCSAP (ORCPT ); Fri, 3 Jun 2022 14:00:15 -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 6D695583B0; Fri, 3 Jun 2022 10:56:18 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 1AD0AB82419; Fri, 3 Jun 2022 17:56:17 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5AFC9C385A9; Fri, 3 Jun 2022 17:56:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278975; bh=2cOlQ4KYOO/RdVnxta68xpDZTkPgvpT6wROgQ21+BnY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=R96LBe1PYju7/oHLv54DcwTqxzoDkgQK5YUWnxnq+C2LKnabiLrf5IdBZDTKIdhoJ COUeLsOrOxdfUa1B8xPqERvAscvw2cgkeOdTrF9A5cRKNf80TegEptUZPTV/vaTPed hriCh+gMtHLcXfp4vgfaxOu7p6/tXq6EuMBz1500= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Pablo Neira Ayuso Subject: [PATCH 5.18 13/67] netfilter: nf_tables: double hook unregistration in netns path Date: Fri, 3 Jun 2022 19:43:14 +0200 Message-Id: <20220603173821.113350962@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- 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); @@ -7301,13 +7316,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, @@ -9751,9 +9778,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 Tue Apr 28 06:30:16 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 BBA4FC433EF for ; Fri, 3 Jun 2022 18:14:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346411AbiFCSOe (ORCPT ); Fri, 3 Jun 2022 14:14:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48530 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346374AbiFCSAP (ORCPT ); Fri, 3 Jun 2022 14:00:15 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E2E0B583BA; Fri, 3 Jun 2022 10:56: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 5C73C6147E; Fri, 3 Jun 2022 17:56:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6DB71C385A9; Fri, 3 Jun 2022 17:56:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278978; bh=+jKGu2m+qotB5j1a1TjLLakeDpMh01+5nUzTVxMt6Vo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=yRuprK4N0uW9KA91MoS6frGxWtvLNGq9+Q/mYRIDBWxLZa6GOlErNDtFuCsiKffKJ pGPouzKVL4rRnlcNRzJ/6vPFDW/7FP8K1GxNETEo4wG3dYvd5rb2P5V1Emj7rpRBtx 2Verpy9UzV4VccgoS66b/61G+LxJcGvs3Cpw34r0= 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.18 14/67] netfilter: conntrack: re-fetch conntrack after insertion Date: Fri, 3 Jun 2022 19:43:15 +0200 Message-Id: <20220603173821.142120889@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- 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 Tue Apr 28 06:30:16 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 8EBD8C433EF for ; Fri, 3 Jun 2022 18:14:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346652AbiFCSOh (ORCPT ); Fri, 3 Jun 2022 14:14:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48936 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346405AbiFCSAQ (ORCPT ); Fri, 3 Jun 2022 14:00:16 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3782F1EC40; Fri, 3 Jun 2022 10:56:22 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 3ED7E611F3; Fri, 3 Jun 2022 17:56:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 44CBAC385A9; Fri, 3 Jun 2022 17:56:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278981; bh=/I0H1cTNR3cP4rD9VlAwUtycmZ5bvrx8pk2QdsQql5M=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=M+PgaI4iRscPhOX0FZ4nv1DXOpLTfRZeAq1AKaeODYR0HrChf+LYDUrPHGQETdJZy t01M9I9wt3pZwXKpzxX5i6b5ASzxvFYL94PDZBtgYzJccaZ9JCpKUiefxNgE5QqErG ip4xsd+WjqWO7nB5nfAgQFUUrmnygp+0AevqIQ6o= 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.18 15/67] KVM: PPC: Book3S HV: fix incorrect NULL check on list iterator Date: Fri, 3 Jun 2022 19:43:16 +0200 Message-Id: <20220603173821.170861468@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- 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 @@ -361,13 +361,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 Tue Apr 28 06:30:16 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 7DA64C433EF for ; Fri, 3 Jun 2022 18:14:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231340AbiFCSOm (ORCPT ); Fri, 3 Jun 2022 14:14:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47812 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346435AbiFCSAR (ORCPT ); Fri, 3 Jun 2022 14:00:17 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 125B558E55; Fri, 3 Jun 2022 10:56: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 863906147E; Fri, 3 Jun 2022 17:56:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 760DDC385B8; Fri, 3 Jun 2022 17:56:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278984; bh=4s/qfcd7m36IGhRpyGgRTOHB6EW2VRul4AL6adni7zI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=g8rKOks9ARihWwoIMGzT0Av5nQilYwO0tVw4of3hBJuqqHrsNP8mpcxcrZncuTRrd iusKVatUolkK+/ErrjgMjNa6MwybGH0JHVD8eq8TTitYfMkqZHmL6risbqnrHHz0b1 JPVUvFNhOwZv70X39d9ezSFBrV1uSN9GkinDgPow= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Zdenek Kaspar , "Maciej S. Szmigiero" , Paolo Bonzini , kvm@vger.kernel.org, Sean Christopherson Subject: [PATCH 5.18 16/67] x86/fpu: KVM: Set the base guest FPU uABI size to sizeof(struct kvm_xsave) Date: Fri, 3 Jun 2022 19:43:17 +0200 Message-Id: <20220603173821.199192719@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 d187ba5312307d51818beafaad87d28a7d939adf upstream. Set the starting uABI size of KVM's guest FPU to 'struct kvm_xsave', i.e. to KVM's historical uABI size. When saving FPU state for usersapce, KVM (well, now the FPU) sets the FP+SSE bits in the XSAVE header even if the host doesn't support XSAVE. Setting the XSAVE header allows the VM to be migrated to a host that does support XSAVE without the new host having to handle FPU state that may or may not be compatible with XSAVE. Setting the uABI size to the host's default size results in out-of-bounds writes (setting the FP+SSE bits) and data corruption (that is thankfully caught by KASAN) when running on hosts without XSAVE, e.g. on Core2 CPUs. WARN if the default size is larger than KVM's historical uABI size; all features that can push the FPU size beyond the historical size must be opt-in. =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 BUG: KASAN: slab-out-of-bounds in fpu_copy_uabi_to_guest_fpstate+0x86/0x1= 30 Read of size 8 at addr ffff888011e33a00 by task qemu-build/681 CPU: 1 PID: 681 Comm: qemu-build Not tainted 5.18.0-rc5-KASAN-amd64 #1 Hardware name: /DG35EC, BIOS ECG3510M.86A.0118.2010.0113.1426 01/13/2010 Call Trace: dump_stack_lvl+0x34/0x45 print_report.cold+0x45/0x575 kasan_report+0x9b/0xd0 fpu_copy_uabi_to_guest_fpstate+0x86/0x130 kvm_arch_vcpu_ioctl+0x72a/0x1c50 [kvm] kvm_vcpu_ioctl+0x47f/0x7b0 [kvm] __x64_sys_ioctl+0x5de/0xc90 do_syscall_64+0x31/0x50 entry_SYSCALL_64_after_hwframe+0x44/0xae Allocated by task 0: (stack is not available) The buggy address belongs to the object at ffff888011e33800 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 0 bytes to the right of 512-byte region [ffff888011e33800, ffff888011e33a00) The buggy address belongs to the physical page: page:0000000089cd4adb refcount:1 mapcount:0 mapping:0000000000000000 inde= x:0x0 pfn:0x11e30 head:0000000089cd4adb order:2 compound_mapcount:0 compound_pincount:0 flags: 0x4000000000010200(slab|head|zone=3D1) raw: 4000000000010200 dead000000000100 dead000000000122 ffff888001041c80 raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888011e33900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888011e33980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff888011e33a00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff888011e33a80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff888011e33b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc =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 Disabling lock debugging due to kernel taint Fixes: be50b2065dfa ("kvm: x86: Add support for getting/setting expanded xs= tate buffer") Fixes: c60427dd50ba ("x86/fpu: Add uabi_size to guest_fpu") Reported-by: Zdenek Kaspar Cc: Maciej S. Szmigiero Cc: Paolo Bonzini Cc: kvm@vger.kernel.org Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Tested-by: Zdenek Kaspar Message-Id: <20220504001219.983513-1-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- arch/x86/kernel/fpu/core.c | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) --- a/arch/x86/kernel/fpu/core.c +++ b/arch/x86/kernel/fpu/core.c @@ -14,6 +14,8 @@ #include #include =20 +#include + #include #include #include @@ -232,7 +234,20 @@ bool fpu_alloc_guest_fpstate(struct fpu_ gfpu->fpstate =3D fpstate; gfpu->xfeatures =3D fpu_user_cfg.default_features; gfpu->perm =3D fpu_user_cfg.default_features; - gfpu->uabi_size =3D fpu_user_cfg.default_size; + + /* + * KVM sets the FP+SSE bits in the XSAVE header when copying FPU state + * to userspace, even when XSAVE is unsupported, so that restoring FPU + * state on a different CPU that does support XSAVE can cleanly load + * the incoming state using its natural XSAVE. In other words, KVM's + * uABI size may be larger than this host's default size. Conversely, + * the default size should never be larger than KVM's base uABI size; + * all features that can expand the uABI size must be opt-in. + */ + gfpu->uabi_size =3D sizeof(struct kvm_xsave); + if (WARN_ON_ONCE(fpu_user_cfg.default_size > gfpu->uabi_size)) + gfpu->uabi_size =3D fpu_user_cfg.default_size; + fpu_init_guest_permissions(gfpu); =20 return true; From nobody Tue Apr 28 06:30:16 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 5B005CCA483 for ; Fri, 3 Jun 2022 18:16:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347399AbiFCSPl (ORCPT ); Fri, 3 Jun 2022 14:15:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48504 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346462AbiFCSAU (ORCPT ); Fri, 3 Jun 2022 14:00:20 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9787058E62; Fri, 3 Jun 2022 10:56: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 37ADDB82369; Fri, 3 Jun 2022 17:56:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 904DFC3411D; Fri, 3 Jun 2022 17:56:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278988; bh=27qRdN9GYw3QvnqkwODMdfeM7nT6M1uBHq5TeeLhpEs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=hyF6EdNmW3C8Y1keFd14Q/lX747yyvcKwmvDlyo1bpjBnBcWlIDTZKbXIk5sFttTL dVN7XpX1T5C30/zqSF7Tk6QasXQfqEBKmoj/9FrcDtjzpwVn0dt3HgEcQ/TfH3vMcg GYq8itlex3FxjpprseKHcq6sB6Kbp/mnjp70LZGI= 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.18 17/67] x86/kvm: Alloc dummy async #PF token outside of raw spinlock Date: Fri, 3 Jun 2022 19:43:18 +0200 Message-Id: <20220603173821.226881426@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- 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 @@ -191,7 +191,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(); @@ -203,28 +203,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 Tue Apr 28 06:30:16 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 23FF1C433EF for ; Fri, 3 Jun 2022 18:14:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346531AbiFCSOq (ORCPT ); Fri, 3 Jun 2022 14:14:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51312 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346478AbiFCSAV (ORCPT ); Fri, 3 Jun 2022 14:00:21 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 677A658E65; Fri, 3 Jun 2022 10:56: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 182FBB82419; Fri, 3 Jun 2022 17:56:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 80237C385A9; Fri, 3 Jun 2022 17:56:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278990; bh=+eAbAqVQE5DVCKFhG3e268Ipd7JndauGDdwdIiUaX2A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=nPamqwUuNS9UOIalxowFi83gBfQxE+VLDSXkLvmo38Fu0QDldtbKtkVxQ59PkS73m T7tElu/KpD5LyHAD2777pWFbMG22O0cLlTFds+Ua/YyNcuwFufV2yAZecY/gQUsnGz VcP6YQGs2XFMUX9vNhr2eZ9EFlDnqVnwAZ36VXgQ= 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.18 18/67] x86, kvm: use correct GFP flags for preemption disabled Date: Fri, 3 Jun 2022 19:43:19 +0200 Message-Id: <20220603173821.254695331@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- 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 @@ -209,7 +209,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 Tue Apr 28 06:30:16 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 E62F3CCA480 for ; Fri, 3 Jun 2022 18:16:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347089AbiFCSPS (ORCPT ); Fri, 3 Jun 2022 14:15:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47676 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346554AbiFCSAY (ORCPT ); Fri, 3 Jun 2022 14:00:24 -0400 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 500F4590BD; Fri, 3 Jun 2022 10:56:38 -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 C0698CE248F; Fri, 3 Jun 2022 17:56:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 79278C385A9; Fri, 3 Jun 2022 17:56:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278994; bh=Zw+tzMWJeAL7D7qrKt21Tx1qu3X28E6qnGNHc4bQWyc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=UKgSoDqxlppZhfI25XW7Xb9yBbazfiYORv+/U99Xq+hQCv+7y9gxQ5/Ygc+HzGYi+ 3jAFhmlOAhjvV/TW0MeUVf89iUjEceCg0+nvyQh5GQq33v0tx270aDP3pcfioo90Gp s8ObDqZXYusdDC6Qrm5KU5UnbB1Gtg1YX2b83sx8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, "Peter Zijlstra (Intel)" , Sean Christopherson , Paolo Bonzini Subject: [PATCH 5.18 19/67] x86/uaccess: Implement macros for CMPXCHG on user addresses Date: Fri, 3 Jun 2022 19:43:20 +0200 Message-Id: <20220603173821.282670906@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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: Peter Zijlstra commit 989b5db215a2f22f89d730b607b071d964780f10 upstream. Add support for CMPXCHG loops on userspace addresses. Provide both an "unsafe" version for tight loops that do their own uaccess begin/end, as well as a "safe" version for use cases where the CMPXCHG is not buried in a loop, e.g. KVM will resume the guest instead of looping when emulation of a guest atomic accesses fails the CMPXCHG. Provide 8-byte versions for 32-bit kernels so that KVM can do CMPXCHG on guest PAE PTEs, which are accessed via userspace addresses. Guard the asm_volatile_goto() variation with CC_HAS_ASM_GOTO_TIED_OUTPUT, the "+m" constraint fails on some compilers that otherwise support CC_HAS_ASM_GOTO_OUTPUT. Cc: stable@vger.kernel.org Signed-off-by: Peter Zijlstra (Intel) Co-developed-by: Sean Christopherson Signed-off-by: Sean Christopherson Message-Id: <20220202004945.2540433-3-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- arch/x86/include/asm/uaccess.h | 142 ++++++++++++++++++++++++++++++++++++= +++++ 1 file changed, 142 insertions(+) --- a/arch/x86/include/asm/uaccess.h +++ b/arch/x86/include/asm/uaccess.h @@ -382,6 +382,103 @@ do { \ =20 #endif // CONFIG_CC_HAS_ASM_GOTO_OUTPUT =20 +#ifdef CONFIG_CC_HAS_ASM_GOTO_TIED_OUTPUT +#define __try_cmpxchg_user_asm(itype, ltype, _ptr, _pold, _new, label) ({ \ + bool success; \ + __typeof__(_ptr) _old =3D (__typeof__(_ptr))(_pold); \ + __typeof__(*(_ptr)) __old =3D *_old; \ + __typeof__(*(_ptr)) __new =3D (_new); \ + asm_volatile_goto("\n" \ + "1: " LOCK_PREFIX "cmpxchg"itype" %[new], %[ptr]\n"\ + _ASM_EXTABLE_UA(1b, %l[label]) \ + : CC_OUT(z) (success), \ + [ptr] "+m" (*_ptr), \ + [old] "+a" (__old) \ + : [new] ltype (__new) \ + : "memory" \ + : label); \ + if (unlikely(!success)) \ + *_old =3D __old; \ + likely(success); }) + +#ifdef CONFIG_X86_32 +#define __try_cmpxchg64_user_asm(_ptr, _pold, _new, label) ({ \ + bool success; \ + __typeof__(_ptr) _old =3D (__typeof__(_ptr))(_pold); \ + __typeof__(*(_ptr)) __old =3D *_old; \ + __typeof__(*(_ptr)) __new =3D (_new); \ + asm_volatile_goto("\n" \ + "1: " LOCK_PREFIX "cmpxchg8b %[ptr]\n" \ + _ASM_EXTABLE_UA(1b, %l[label]) \ + : CC_OUT(z) (success), \ + "+A" (__old), \ + [ptr] "+m" (*_ptr) \ + : "b" ((u32)__new), \ + "c" ((u32)((u64)__new >> 32)) \ + : "memory" \ + : label); \ + if (unlikely(!success)) \ + *_old =3D __old; \ + likely(success); }) +#endif // CONFIG_X86_32 +#else // !CONFIG_CC_HAS_ASM_GOTO_TIED_OUTPUT +#define __try_cmpxchg_user_asm(itype, ltype, _ptr, _pold, _new, label) ({ \ + int __err =3D 0; \ + bool success; \ + __typeof__(_ptr) _old =3D (__typeof__(_ptr))(_pold); \ + __typeof__(*(_ptr)) __old =3D *_old; \ + __typeof__(*(_ptr)) __new =3D (_new); \ + asm volatile("\n" \ + "1: " LOCK_PREFIX "cmpxchg"itype" %[new], %[ptr]\n"\ + CC_SET(z) \ + "2:\n" \ + _ASM_EXTABLE_TYPE_REG(1b, 2b, EX_TYPE_EFAULT_REG, \ + %[errout]) \ + : CC_OUT(z) (success), \ + [errout] "+r" (__err), \ + [ptr] "+m" (*_ptr), \ + [old] "+a" (__old) \ + : [new] ltype (__new) \ + : "memory", "cc"); \ + if (unlikely(__err)) \ + goto label; \ + if (unlikely(!success)) \ + *_old =3D __old; \ + likely(success); }) + +#ifdef CONFIG_X86_32 +/* + * Unlike the normal CMPXCHG, hardcode ECX for both success/fail and error. + * There are only six GPRs available and four (EAX, EBX, ECX, and EDX) are + * hardcoded by CMPXCHG8B, leaving only ESI and EDI. If the compiler uses + * both ESI and EDI for the memory operand, compilation will fail if the e= rror + * is an input+output as there will be no register available for input. + */ +#define __try_cmpxchg64_user_asm(_ptr, _pold, _new, label) ({ \ + int __result; \ + __typeof__(_ptr) _old =3D (__typeof__(_ptr))(_pold); \ + __typeof__(*(_ptr)) __old =3D *_old; \ + __typeof__(*(_ptr)) __new =3D (_new); \ + asm volatile("\n" \ + "1: " LOCK_PREFIX "cmpxchg8b %[ptr]\n" \ + "mov $0, %%ecx\n\t" \ + "setz %%cl\n" \ + "2:\n" \ + _ASM_EXTABLE_TYPE_REG(1b, 2b, EX_TYPE_EFAULT_REG, %%ecx) \ + : [result]"=3Dc" (__result), \ + "+A" (__old), \ + [ptr] "+m" (*_ptr) \ + : "b" ((u32)__new), \ + "c" ((u32)((u64)__new >> 32)) \ + : "memory", "cc"); \ + if (unlikely(__result < 0)) \ + goto label; \ + if (unlikely(!__result)) \ + *_old =3D __old; \ + likely(__result); }) +#endif // CONFIG_X86_32 +#endif // CONFIG_CC_HAS_ASM_GOTO_TIED_OUTPUT + /* FIXME: this hack is definitely wrong -AK */ struct __large_struct { unsigned long buf[100]; }; #define __m(x) (*(struct __large_struct __user *)(x)) @@ -474,6 +571,51 @@ do { \ } while (0) #endif // CONFIG_CC_HAS_ASM_GOTO_OUTPUT =20 +extern void __try_cmpxchg_user_wrong_size(void); + +#ifndef CONFIG_X86_32 +#define __try_cmpxchg64_user_asm(_ptr, _oldp, _nval, _label) \ + __try_cmpxchg_user_asm("q", "r", (_ptr), (_oldp), (_nval), _label) +#endif + +/* + * Force the pointer to u to match the size expected by the asm help= er. + * clang/LLVM compiles all cases and only discards the unused paths after + * processing errors, which breaks i386 if the pointer is an 8-byte value. + */ +#define unsafe_try_cmpxchg_user(_ptr, _oldp, _nval, _label) ({ \ + bool __ret; \ + __chk_user_ptr(_ptr); \ + switch (sizeof(*(_ptr))) { \ + case 1: __ret =3D __try_cmpxchg_user_asm("b", "q", \ + (__force u8 *)(_ptr), (_oldp), \ + (_nval), _label); \ + break; \ + case 2: __ret =3D __try_cmpxchg_user_asm("w", "r", \ + (__force u16 *)(_ptr), (_oldp), \ + (_nval), _label); \ + break; \ + case 4: __ret =3D __try_cmpxchg_user_asm("l", "r", \ + (__force u32 *)(_ptr), (_oldp), \ + (_nval), _label); \ + break; \ + case 8: __ret =3D __try_cmpxchg64_user_asm((__force u64 *)(_ptr), (_oldp)= ,\ + (_nval), _label); \ + break; \ + default: __try_cmpxchg_user_wrong_size(); \ + } \ + __ret; }) + +/* "Returns" 0 on success, 1 on failure, -EFAULT if the access faults. */ +#define __try_cmpxchg_user(_ptr, _oldp, _nval, _label) ({ \ + int __ret =3D -EFAULT; \ + __uaccess_begin_nospec(); \ + __ret =3D !unsafe_try_cmpxchg_user(_ptr, _oldp, _nval, _label); \ +_label: \ + __uaccess_end(); \ + __ret; \ + }) + /* * We want the unsafe accessors to always be inlined and use * the error labels - thus the macro games. From nobody Tue Apr 28 06:30:16 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 0FC0FC43334 for ; Fri, 3 Jun 2022 18:16:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346872AbiFCSO5 (ORCPT ); Fri, 3 Jun 2022 14:14:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50352 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346581AbiFCSA0 (ORCPT ); Fri, 3 Jun 2022 14:00:26 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 154B55908E; Fri, 3 Jun 2022 10:56:39 -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 4834BB82369; Fri, 3 Jun 2022 17:56:38 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8FC97C385A9; Fri, 3 Jun 2022 17:56:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278997; bh=lNOmLlFQuyuci5IwSKVo0uhTC3PXQ5cfKd6PwOA3j3o=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=gxtxVgro5XsC1ADaMS7hAUJVUYi12BcG7o0HIWiMPVQKXHdvXoEnhmm3mwJt5eyU1 rQg4FfVJyIzx/I5gfGa2kekbfZzd53+emrECgS0ND7sT1AG5rBSrlSjkVWYIHOOs7N 2MLwO71322nSpHWo6vHAQ2ZjQNRc+jJHnrcfx+2E= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Tadeusz Struk , syzbot+6cde2282daa792c49ab8@syzkaller.appspotmail.com, Sean Christopherson , Paolo Bonzini Subject: [PATCH 5.18 20/67] KVM: x86: Use __try_cmpxchg_user() to update guest PTE A/D bits Date: Fri, 3 Jun 2022 19:43:21 +0200 Message-Id: <20220603173821.309910746@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 f122dfe4476890d60b8c679128cd2259ec96a24c upstream. Use the recently introduced __try_cmpxchg_user() to update guest PTE A/D bits instead of mapping the PTE into kernel address space. The VM_PFNMAP path is broken as it assumes that vm_pgoff is the base pfn of the mapped VMA range, which is conceptually wrong as vm_pgoff is the offset relative to the file and has nothing to do with the pfn. The horrific hack worked for the original use case (backing guest memory with /dev/mem), but leads to accessing "random" pfns for pretty much any other VM_PFNMAP case. Fixes: bd53cb35a3e9 ("X86/KVM: Handle PFNs outside of kernel reach when tou= ching GPTEs") Debugged-by: Tadeusz Struk Tested-by: Tadeusz Struk Reported-by: syzbot+6cde2282daa792c49ab8@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-Id: <20220202004945.2540433-4-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- arch/x86/kvm/mmu/paging_tmpl.h | 38 +-----------------------------------= -- 1 file changed, 1 insertion(+), 37 deletions(-) --- a/arch/x86/kvm/mmu/paging_tmpl.h +++ b/arch/x86/kvm/mmu/paging_tmpl.h @@ -144,42 +144,6 @@ static bool FNAME(is_rsvd_bits_set)(stru FNAME(is_bad_mt_xwr)(&mmu->guest_rsvd_check, gpte); } =20 -static int FNAME(cmpxchg_gpte)(struct kvm_vcpu *vcpu, struct kvm_mmu *mmu, - pt_element_t __user *ptep_user, unsigned index, - pt_element_t orig_pte, pt_element_t new_pte) -{ - signed char r; - - if (!user_access_begin(ptep_user, sizeof(pt_element_t))) - return -EFAULT; - -#ifdef CMPXCHG - asm volatile("1:" LOCK_PREFIX CMPXCHG " %[new], %[ptr]\n" - "setnz %b[r]\n" - "2:" - _ASM_EXTABLE_TYPE_REG(1b, 2b, EX_TYPE_EFAULT_REG, %k[r]) - : [ptr] "+m" (*ptep_user), - [old] "+a" (orig_pte), - [r] "=3Dq" (r) - : [new] "r" (new_pte) - : "memory"); -#else - asm volatile("1:" LOCK_PREFIX "cmpxchg8b %[ptr]\n" - "setnz %b[r]\n" - "2:" - _ASM_EXTABLE_TYPE_REG(1b, 2b, EX_TYPE_EFAULT_REG, %k[r]) - : [ptr] "+m" (*ptep_user), - [old] "+A" (orig_pte), - [r] "=3Dq" (r) - : [new_lo] "b" ((u32)new_pte), - [new_hi] "c" ((u32)(new_pte >> 32)) - : "memory"); -#endif - - user_access_end(); - return r; -} - static bool FNAME(prefetch_invalid_gpte)(struct kvm_vcpu *vcpu, struct kvm_mmu_page *sp, u64 *spte, u64 gpte) @@ -278,7 +242,7 @@ static int FNAME(update_accessed_dirty_b if (unlikely(!walker->pte_writable[level - 1])) continue; =20 - ret =3D FNAME(cmpxchg_gpte)(vcpu, mmu, ptep_user, index, orig_pte, pte); + ret =3D __try_cmpxchg_user(ptep_user, &orig_pte, pte, fault); if (ret) return ret; From nobody Tue Apr 28 06:30:16 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 343C4CCA482 for ; Fri, 3 Jun 2022 18:16:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347159AbiFCSP3 (ORCPT ); Fri, 3 Jun 2022 14:15:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47082 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346656AbiFCSA2 (ORCPT ); Fri, 3 Jun 2022 14:00:28 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B267DBD6; Fri, 3 Jun 2022 10:56:44 -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 297EA61555; Fri, 3 Jun 2022 17:56:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1BC69C385A9; Fri, 3 Jun 2022 17:56:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279003; bh=TbpKUtNHnEOzZffoMTxedrzce7IA7XzbzevMWJ2iUtU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=o42VDqv6e+jZy6WGJbIbMx60d/GNnaOCLTGv7trtwQl2tSNENDQstXN0cUjPKj3m+ YDImadZllGFwSMlcj71RD31G/+coFKTrRXEhEuMGV4rPf1ewqah0AYgi2kemEFqY5+ /otmqNBeksZhWbGfekXPWt8mxTBNNmtF/ani4RVY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Sean Christopherson , Paolo Bonzini Subject: [PATCH 5.18 21/67] KVM: x86: Use __try_cmpxchg_user() to emulate atomic accesses Date: Fri, 3 Jun 2022 19:43:22 +0200 Message-Id: <20220603173821.337659871@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 1c2361f667f3648855ceae25f1332c18413fdb9f upstream. Use the recently introduce __try_cmpxchg_user() to emulate atomic guest accesses via the associated userspace address instead of mapping the backing pfn into kernel address space. Using kvm_vcpu_map() is unsafe as it does not coordinate with KVM's mmu_notifier to ensure the hva=3D>pfn translation isn't changed/unmapped in the memremap() path, i.e. when there's no struct page and thus no elevated refcount. Fixes: 42e35f8072c3 ("KVM/X86: Use kvm_vcpu_map in emulator_cmpxchg_emulate= d") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-Id: <20220202004945.2540433-5-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- arch/x86/kvm/x86.c | 35 ++++++++++++++--------------------- 1 file changed, 14 insertions(+), 21 deletions(-) --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -7229,15 +7229,8 @@ static int emulator_write_emulated(struc exception, &write_emultor); } =20 -#define CMPXCHG_TYPE(t, ptr, old, new) \ - (cmpxchg((t *)(ptr), *(t *)(old), *(t *)(new)) =3D=3D *(t *)(old)) - -#ifdef CONFIG_X86_64 -# define CMPXCHG64(ptr, old, new) CMPXCHG_TYPE(u64, ptr, old, new) -#else -# define CMPXCHG64(ptr, old, new) \ - (cmpxchg64((u64 *)(ptr), *(u64 *)(old), *(u64 *)(new)) =3D=3D *(u64 *)(ol= d)) -#endif +#define emulator_try_cmpxchg_user(t, ptr, old, new) \ + (__try_cmpxchg_user((t __user *)(ptr), (t *)(old), *(t *)(new), efault ##= t)) =20 static int emulator_cmpxchg_emulated(struct x86_emulate_ctxt *ctxt, unsigned long addr, @@ -7246,12 +7239,11 @@ static int emulator_cmpxchg_emulated(str unsigned int bytes, struct x86_exception *exception) { - struct kvm_host_map map; struct kvm_vcpu *vcpu =3D emul_to_vcpu(ctxt); u64 page_line_mask; + unsigned long hva; gpa_t gpa; - char *kaddr; - bool exchanged; + int r; =20 /* guests cmpxchg8b have to be emulated atomically */ if (bytes > 8 || (bytes & (bytes - 1))) @@ -7275,31 +7267,32 @@ static int emulator_cmpxchg_emulated(str if (((gpa + bytes - 1) & page_line_mask) !=3D (gpa & page_line_mask)) goto emul_write; =20 - if (kvm_vcpu_map(vcpu, gpa_to_gfn(gpa), &map)) + hva =3D kvm_vcpu_gfn_to_hva(vcpu, gpa_to_gfn(gpa)); + if (kvm_is_error_hva(addr)) goto emul_write; =20 - kaddr =3D map.hva + offset_in_page(gpa); + hva +=3D offset_in_page(gpa); =20 switch (bytes) { case 1: - exchanged =3D CMPXCHG_TYPE(u8, kaddr, old, new); + r =3D emulator_try_cmpxchg_user(u8, hva, old, new); break; case 2: - exchanged =3D CMPXCHG_TYPE(u16, kaddr, old, new); + r =3D emulator_try_cmpxchg_user(u16, hva, old, new); break; case 4: - exchanged =3D CMPXCHG_TYPE(u32, kaddr, old, new); + r =3D emulator_try_cmpxchg_user(u32, hva, old, new); break; case 8: - exchanged =3D CMPXCHG64(kaddr, old, new); + r =3D emulator_try_cmpxchg_user(u64, hva, old, new); break; default: BUG(); } =20 - kvm_vcpu_unmap(vcpu, &map, true); - - if (!exchanged) + if (r < 0) + goto emul_write; + if (r) return X86EMUL_CMPXCHG_FAILED; =20 kvm_page_track_write(vcpu, gpa, new, bytes); From nobody Tue Apr 28 06:30:16 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 13400CCA481 for ; Fri, 3 Jun 2022 18:16:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347124AbiFCSPW (ORCPT ); Fri, 3 Jun 2022 14:15:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48570 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346808AbiFCSAf (ORCPT ); Fri, 3 Jun 2022 14:00:35 -0400 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4922712631; Fri, 3 Jun 2022 10:56: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 sin.source.kernel.org (Postfix) with ESMTPS id 0C043CE233B; Fri, 3 Jun 2022 17:56:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0F41EC385A9; Fri, 3 Jun 2022 17:56:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279006; bh=TQMi84fPYBbRRevC3hnf7QvIdSkLuhB46VbI3kQbPvg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=gRtcUx1ffKSdECKDabZ86nJy5TUp56Rg6wsCx7jhW7zfuhKj2F79LHdPQki+TcUqu hivRIgkpoZoAhFIIZMV3tDecL0p2w9uQwfHGiryDZwIg8eXvkhFtLwRjQustkqpPX+ lyhiZ1R/6zS2wqlRyVCNyG395U97rB9qQxZEqb1Y= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Maxim Levitsky , Sean Christopherson , Vitaly Kuznetsov , Paolo Bonzini Subject: [PATCH 5.18 22/67] KVM: x86: fix typo in __try_cmpxchg_user causing non-atomicness Date: Fri, 3 Jun 2022 19:43:23 +0200 Message-Id: <20220603173821.365331799@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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: Maxim Levitsky commit 33fbe6befa622c082f7d417896832856814bdde0 upstream. This shows up as a TDP MMU leak when running nested. Non-working cmpxchg o= n L0 relies makes L1 install two different shadow pages under same spte, and one= of them is leaked. Fixes: 1c2361f667f36 ("KVM: x86: Use __try_cmpxchg_user() to emulate atomic= accesses") Signed-off-by: Maxim Levitsky Message-Id: <20220512101420.306759-1-mlevitsk@redhat.com> Reviewed-by: Sean Christopherson Reviewed-by: Vitaly Kuznetsov Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- arch/x86/kvm/x86.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -7268,7 +7268,7 @@ static int emulator_cmpxchg_emulated(str goto emul_write; =20 hva =3D kvm_vcpu_gfn_to_hva(vcpu, gpa_to_gfn(gpa)); - if (kvm_is_error_hva(addr)) + if (kvm_is_error_hva(hva)) goto emul_write; =20 hva +=3D offset_in_page(gpa); From nobody Tue Apr 28 06:30:16 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 94078C433EF for ; Fri, 3 Jun 2022 18:16:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346952AbiFCSPE (ORCPT ); Fri, 3 Jun 2022 14:15:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47682 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346702AbiFCSAa (ORCPT ); Fri, 3 Jun 2022 14:00:30 -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 4EAD41EEC5; Fri, 3 Jun 2022 10:56: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 1B970615DA; Fri, 3 Jun 2022 17:56:50 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0EEDCC385A9; Fri, 3 Jun 2022 17:56:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279009; bh=DLAtzt7prpBftpea8sCEQp4LJHuBMCHTk6VeyQOw2DI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=gCNBmnUf2wnxPHF4WvHHHodEeXTvtVejL1ALWV//XizIYjLtCfW+Ief8eyNfKLcTV nzbe2R9JXSdDCeVrllCPeEEGYD+W6Ywm+pgrU4relO/mTgHLQZbUeig6832CE66Tf0 1ysj/0lq5bnIZGZqyiSl3W0y8SLNvx6DXaM8fgFc= 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.18 23/67] KVM: x86: avoid calling x86 emulator without a decoded instruction Date: Fri, 3 Jun 2022 19:43:24 +0200 Message-Id: <20220603173821.393616220@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- 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 @@ -8244,7 +8244,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)) { @@ -8313,25 +8313,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); @@ -8364,6 +8362,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 Tue Apr 28 06:30:16 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 B644ECCA47C for ; Fri, 3 Jun 2022 18:16:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346987AbiFCSPI (ORCPT ); Fri, 3 Jun 2022 14:15:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51096 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346748AbiFCSAd (ORCPT ); Fri, 3 Jun 2022 14:00:33 -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 886512BFD; Fri, 3 Jun 2022 10:56:53 -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 2E857615E3; Fri, 3 Jun 2022 17:56:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 208C8C385A9; Fri, 3 Jun 2022 17:56:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279012; bh=SF7E+IPj5PcsCtp+gwrO4WkiOXIbDQbJq8FCHx19T88=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Rbx6Hs9J+Foht+GZaZ9aX3Y72ntjVkNkZLiEAYbrMOkreie+z0TLXbrfdkeXKgTmV 7vpCzgaL1i5GRx0jx/zxK0oWhBib4KJJ7N1Q/up1khlXHqhMWmcYSG+FGOhgRxF9Ff iOELkUfywVK/UMrpJrECe+KyKA7HUKp9sBR5AyYo= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Maxim Levitsky , Paolo Bonzini Subject: [PATCH 5.18 24/67] KVM: x86: avoid loading a vCPU after .vm_destroy was called Date: Fri, 3 Jun 2022 19:43:25 +0200 Message-Id: <20220603173821.422587327@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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: Maxim Levitsky commit 6fcee03df6a1a3101a77344be37bb85c6142d56c upstream. This can cause various unexpected issues, since VM is partially destroyed at that point. For example when AVIC is enabled, this causes avic_vcpu_load to access physical id page entry which is already freed by .vm_destroy. Fixes: 8221c1370056 ("svm: Manage vcpu load/unload when enable AVIC") Cc: stable@vger.kernel.org Signed-off-by: Maxim Levitsky Message-Id: <20220322172449.235575-2-mlevitsk@redhat.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- arch/x86/kvm/x86.c | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -11747,20 +11747,15 @@ static void kvm_unload_vcpu_mmu(struct k vcpu_put(vcpu); } =20 -static void kvm_free_vcpus(struct kvm *kvm) +static void kvm_unload_vcpu_mmus(struct kvm *kvm) { unsigned long i; struct kvm_vcpu *vcpu; =20 - /* - * Unpin any mmu pages first. - */ kvm_for_each_vcpu(i, vcpu, kvm) { kvm_clear_async_pf_completion_queue(vcpu); kvm_unload_vcpu_mmu(vcpu); } - - kvm_destroy_vcpus(kvm); } =20 void kvm_arch_sync_events(struct kvm *kvm) @@ -11866,11 +11861,12 @@ void kvm_arch_destroy_vm(struct kvm *kvm __x86_set_memory_region(kvm, TSS_PRIVATE_MEMSLOT, 0, 0); mutex_unlock(&kvm->slots_lock); } + kvm_unload_vcpu_mmus(kvm); static_call_cond(kvm_x86_vm_destroy)(kvm); kvm_free_msr_filter(srcu_dereference_check(kvm->arch.msr_filter, &kvm->sr= cu, 1)); kvm_pic_destroy(kvm); kvm_ioapic_destroy(kvm); - kvm_free_vcpus(kvm); + kvm_destroy_vcpus(kvm); kvfree(rcu_dereference_check(kvm->arch.apic_map, 1)); kfree(srcu_dereference_check(kvm->arch.pmu_event_filter, &kvm->srcu, 1)); kvm_mmu_uninit_vm(kvm); From nobody Tue Apr 28 06:30:16 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 C6D45CCA473 for ; Fri, 3 Jun 2022 18:16:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347063AbiFCSPO (ORCPT ); Fri, 3 Jun 2022 14:15:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47602 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346972AbiFCSAs (ORCPT ); Fri, 3 Jun 2022 14:00:48 -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 C5EBBA468; Fri, 3 Jun 2022 10:57: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 ams.source.kernel.org (Postfix) with ESMTPS id D312AB82419; Fri, 3 Jun 2022 17:56:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4994BC385B8; Fri, 3 Jun 2022 17:56:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279015; bh=9zj7v1rHX8IEL130KgzECn4tAv637z1ax2CPmS3v65I=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=W1Mafr2YmEeaca2aYxNNDowY1WRYnqwLjCttqoVxHLx90n00hP2gKaa93IVm4pLIX 8z5a29VuADlvo3ObyeWxkTeilUoXFh1c0TqDWRgZ4z8tagszR/NeONaD4wFay4+9t9 4HcG/4cU578KAMOS7Xz8QGxgyrPGRhcCHSDgdAhA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Yanfei Xu , Paolo Bonzini Subject: [PATCH 5.18 25/67] KVM: x86: Fix the intel_pt PMI handling wrongly considered from guest Date: Fri, 3 Jun 2022 19:43:26 +0200 Message-Id: <20220603173821.450667939@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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: Yanfei Xu commit ffd1925a596ce68bed7d81c61cb64bc35f788a9d upstream. When kernel handles the vm-exit caused by external interrupts and NMI, it always sets kvm_intr_type to tell if it's dealing an IRQ or NMI. For the PMI scenario, it could be IRQ or NMI. However, intel_pt PMIs are only generated for HARDWARE perf events, and HARDWARE events are always configured to generate NMIs. Use kvm_handling_nmi_from_guest() to precisely identify if the intel_pt PMI came from the guest; this avoids false positives if an intel_pt PMI/NMI arrives while the host is handling an unrelated IRQ VM-Exit. Fixes: db215756ae59 ("KVM: x86: More precisely identify NMI from guest when= handling PMI") Signed-off-by: Yanfei Xu Message-Id: <20220523140821.1345605-1-yanfei.xu@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- arch/x86/kvm/vmx/vmx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/x86/kvm/vmx/vmx.c +++ b/arch/x86/kvm/vmx/vmx.c @@ -7856,7 +7856,7 @@ static unsigned int vmx_handle_intel_pt_ struct kvm_vcpu *vcpu =3D kvm_get_running_vcpu(); =20 /* '0' on failure so that the !PT case can use a RET0 static call. */ - if (!kvm_arch_pmi_in_guest(vcpu)) + if (!vcpu || !kvm_handling_nmi_from_guest(vcpu)) return 0; =20 kvm_make_request(KVM_REQ_PMI, vcpu); From nobody Tue Apr 28 06:30:16 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 2E5C6CCA489 for ; Fri, 3 Jun 2022 18:16:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348142AbiFCSQX (ORCPT ); Fri, 3 Jun 2022 14:16:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40290 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346102AbiFCSBk (ORCPT ); Fri, 3 Jun 2022 14:01:40 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D95304A906; Fri, 3 Jun 2022 10:57:41 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id E7F38B8241E; Fri, 3 Jun 2022 17:56:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3F6B7C385A9; Fri, 3 Jun 2022 17:56:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279018; bh=visI1TTHwmCqbAwL6UAvfvNG1u2FwYk4D+zDUFCK6Sc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=EEH0YNuEdLVBssrhhbFCr5rqdcryulFM1vz0YfY4NkeF9JlReHJ8rIsp3Z5wlwh6M TTu7PSxVRQBT0TdWVUDMe4UJssQ8qjJ9nSdOcmQlY5etXmexusyQVgGvOnoScWoYmj ltKR5YbQwwj09I14+mjfuuDauhgZZgZ2XbbhD2Pw= 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.18 26/67] KVM: x86: Drop WARNs that assert a triple fault never "escapes" from L2 Date: Fri, 3 Jun 2022 19:43:27 +0200 Message-Id: <20220603173821.478797713@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- 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 @@ -819,9 +819,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 @@ -4518,9 +4518,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 Tue Apr 28 06:30:16 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 3FEC8CCA48C for ; Fri, 3 Jun 2022 18:16:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348175AbiFCSQ3 (ORCPT ); Fri, 3 Jun 2022 14:16:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40996 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346456AbiFCSBu (ORCPT ); Fri, 3 Jun 2022 14:01:50 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 50A8B56C25; Fri, 3 Jun 2022 10:57: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 8F1BD60F3B; Fri, 3 Jun 2022 17:57:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 862C4C341C6; Fri, 3 Jun 2022 17:57:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279022; bh=4VdjQBOf3jnTTd1WKTY/qJzK8WAWb5QYzkD9VU0fllk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=cdyvD2mzeX4Nr2uRjDLLqDVC7HWE5o/wfT6DoCoiY/algPHyF3wVL4TkvZ5TLwiME h5Dp7Zu7OggOiBK4NKK7T/8cUePYcuUWzBqKoIzAtd2SKlnc1btjKmHi/CFWsIZPsp GgrHKvA5XVg9Hskx5nIjVH/tUzUUhHUrUDmN0H8Y= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Hou Wenlong , Lai Jiangshan , Paolo Bonzini Subject: [PATCH 5.18 27/67] KVM: x86/mmu: Dont rebuild page when the page is synced and no tlb flushing is required Date: Fri, 3 Jun 2022 19:43:28 +0200 Message-Id: <20220603173821.507311892@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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: Hou Wenlong commit 8d5678a76689acbf91245a3791fe853ab773090f upstream. Before Commit c3e5e415bc1e6 ("KVM: X86: Change kvm_sync_page() to return true when remote flush is needed"), the return value of kvm_sync_page() indicates whether the page is synced, and kvm_mmu_get_page() would rebuild page when the sync fails. But now, kvm_sync_page() returns false when the page is synced and no tlb flushing is required, which leads to rebuild page in kvm_mmu_get_page(). So return the return value of mmu->sync_page() directly and check it in kvm_mmu_get_page(). If the sync fails, the page will be zapped and the invalid_list is not empty, so set flush as true is accepted in mmu_sync_children(). Cc: stable@vger.kernel.org Fixes: c3e5e415bc1e6 ("KVM: X86: Change kvm_sync_page() to return true when= remote flush is needed") Signed-off-by: Hou Wenlong Acked-by: Lai Jiangshan Message-Id: <0dabeeb789f57b0d793f85d073893063e692032d.1647336064.git.houwen= long.hwl@antgroup.com> [mmu_sync_children should not flush if the page is zapped. - Paolo] Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- arch/x86/kvm/mmu/mmu.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) --- a/arch/x86/kvm/mmu/mmu.c +++ b/arch/x86/kvm/mmu/mmu.c @@ -1843,17 +1843,14 @@ static void kvm_mmu_commit_zap_page(stru &(_kvm)->arch.mmu_page_hash[kvm_page_table_hashfn(_gfn)]) \ if ((_sp)->gfn !=3D (_gfn) || (_sp)->role.direct) {} else =20 -static bool kvm_sync_page(struct kvm_vcpu *vcpu, struct kvm_mmu_page *sp, +static int kvm_sync_page(struct kvm_vcpu *vcpu, struct kvm_mmu_page *sp, struct list_head *invalid_list) { int ret =3D vcpu->arch.mmu->sync_page(vcpu, sp); =20 - if (ret < 0) { + if (ret < 0) kvm_mmu_prepare_zap_page(vcpu->kvm, sp, invalid_list); - return false; - } - - return !!ret; + return ret; } =20 static bool kvm_mmu_remote_flush_or_zap(struct kvm *kvm, @@ -1975,7 +1972,7 @@ static int mmu_sync_children(struct kvm_ =20 for_each_sp(pages, sp, parents, i) { kvm_unlink_unsync_page(vcpu->kvm, sp); - flush |=3D kvm_sync_page(vcpu, sp, &invalid_list); + flush |=3D kvm_sync_page(vcpu, sp, &invalid_list) > 0; mmu_pages_clear_parents(&parents); } if (need_resched() || rwlock_needbreak(&vcpu->kvm->mmu_lock)) { @@ -2016,6 +2013,7 @@ static struct kvm_mmu_page *kvm_mmu_get_ struct hlist_head *sp_list; unsigned quadrant; struct kvm_mmu_page *sp; + int ret; int collisions =3D 0; LIST_HEAD(invalid_list); =20 @@ -2068,11 +2066,13 @@ static struct kvm_mmu_page *kvm_mmu_get_ * If the sync fails, the page is zapped. If so, break * in order to rebuild it. */ - if (!kvm_sync_page(vcpu, sp, &invalid_list)) + ret =3D kvm_sync_page(vcpu, sp, &invalid_list); + if (ret < 0) break; =20 WARN_ON(!list_empty(&invalid_list)); - kvm_flush_remote_tlbs(vcpu->kvm); + if (ret > 0) + kvm_flush_remote_tlbs(vcpu->kvm); } =20 __clear_sp_write_flooding_count(sp); From nobody Tue Apr 28 06:30:16 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 9D609CCA48B for ; Fri, 3 Jun 2022 18:16:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348321AbiFCSQf (ORCPT ); Fri, 3 Jun 2022 14:16:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46466 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346320AbiFCSEz (ORCPT ); Fri, 3 Jun 2022 14:04:55 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 00E135712F; Fri, 3 Jun 2022 10:58: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 366A5B82189; Fri, 3 Jun 2022 17:57:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 96FB2C385B8; Fri, 3 Jun 2022 17:57:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279025; bh=wTV5cVFc5rKLzg7MqcEFuVDlN6PsOXkUdWpdiX9W7qI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=XLDvkMc/Bq4S5SvdIZCQ4GpGJxuUhdFFKrMHdTxTokL/G9HZ3MYKRK1sJgtt60Hga qMJbc6vmDaov765QYnsRTe9GuHHCMkffsGFlDxaBte99WHRXu9oPUiOb+44u9MaiUM gZUT/veLR3/hG1A/vChceoU2IRHPbeyU4ugirBtM= 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.18 28/67] KVM: SVM: Use kzalloc for sev ioctl interfaces to prevent kernel data leak Date: Fri, 3 Jun 2022 19:43:29 +0200 Message-Id: <20220603173821.535586563@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- 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 @@ -688,7 +688,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 @@ -808,7 +808,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 @@ -1094,7 +1094,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 @@ -1176,7 +1176,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 @@ -1300,11 +1300,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 Tue Apr 28 06:30:16 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 8999ACCA48D for ; Fri, 3 Jun 2022 18:16:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348256AbiFCSQc (ORCPT ); Fri, 3 Jun 2022 14:16:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40290 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238830AbiFCSEz (ORCPT ); Fri, 3 Jun 2022 14:04:55 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9CE2A57111; Fri, 3 Jun 2022 10:58: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 1C080B8241D; Fri, 3 Jun 2022 17:57:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7BB87C385A9; Fri, 3 Jun 2022 17:57:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279027; bh=tSQXz/ZFbI2pYTh4TigjjrPwJuuXCKdaX9A7q3dypck=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=CIqgM5bzOWqa5VptNCzQD9VdXr45N0olLKqaLNocTIOjNiB5rq6sSiMWCntiJ63Gv 0t5f6Nh2t+FjF4/QWuJdJVA4dAJXuDcgo9GmERTksHIhDuPA1PQDlqQhz07O+zr/Z8 Ko8USy7XCVE1K8lmrZG0L0luQUeEboqpkbL8G7m0= 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.18 29/67] crypto: caam - fix i.MX6SX entropy delay value Date: Fri, 3 Jun 2022 19:43:30 +0200 Message-Id: <20220603173821.563313170@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- 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 Tue Apr 28 06:30:16 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 96C8BC433EF for ; Fri, 3 Jun 2022 18:21:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347710AbiFCSVD (ORCPT ); Fri, 3 Jun 2022 14:21:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36556 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346935AbiFCSFb (ORCPT ); Fri, 3 Jun 2022 14:05:31 -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 A6D1C5713A; Fri, 3 Jun 2022 10:58: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 6D9B461555; Fri, 3 Jun 2022 17:57:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6F527C385A9; Fri, 3 Jun 2022 17:57:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279030; bh=sQ0GPSl5NoQwPN9POfGGNsMy+Sxch4CTIxQGvcHIVJU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=d8QglLYaP7lLjnWrtvETevHqI7ugDa11zvYxCcTdkFthbziZEFq9OzAwTuNo/QvgE LAKQw4yIVZHGEleaOU4SWPj0va8wfPz1xvv/1RE+z9aGhCO5Ea+QvhHW/t/Hg1dnpp dz9zFPe+twF6d2Pn2wy51RrxUAaPVp2qGG336XQQ= 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.18 30/67] crypto: ecrdsa - Fix incorrect use of vli_cmp Date: Fri, 3 Jun 2022 19:43:31 +0200 Message-Id: <20220603173821.590743078@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- 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 Tue Apr 28 06:30:16 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 D3A39CCA48E for ; Fri, 3 Jun 2022 18:16:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348595AbiFCSQt (ORCPT ); Fri, 3 Jun 2022 14:16:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47032 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347031AbiFCSFf (ORCPT ); Fri, 3 Jun 2022 14:05:35 -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 2348F5A5A1; Fri, 3 Jun 2022 10:58: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 58CB861590; Fri, 3 Jun 2022 17:57:17 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 641DBC385A9; Fri, 3 Jun 2022 17:57:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279036; bh=4o9alDAbMoDW4hxPro7ZAS1S3+hfNRg2wwyqpO25xyw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=yQ++FcnUJ+eUCTmOd19rb4ZJdWNF5/OZ3r1pYEBe+AB8liDw2Nz8HjBk5jF31ToeD qTql/ONo96MGh+1Hlf7rArj/jIUYzbfecQKvA2RduVoV0FW/6CL7sBKNcIuIlSKG0t IjTGRDG3iQosVZHBSxj/WCF6LRmGyJlhVBXgIxvc= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Marco Chiappero , Giovanni Cabiddu , Herbert Xu Subject: [PATCH 5.18 31/67] crypto: qat - rework the VF2PF interrupt handling logic Date: Fri, 3 Jun 2022 19:43:32 +0200 Message-Id: <20220603173821.618346787@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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: Marco Chiappero commit c690c7f6312ce69b426af08ae1da2b9e48a0246f upstream. Change the VF2PF interrupt handler in the PF ISR and the definition of the internal PFVF API to correct the current implementation, which can result in missed interrupts. More specifically, current HW generations consider a write to the mask register, regardless of the value, as an acknowledge of any pending VF2PF interrupt. Therefore, if there is an interrupt between the source register read and the mask register write, such interrupt will not be delivered and silently acknowledged, resulting in a lost VF2PF message. To work around the problem, rather than disabling specific interrupts, disable all the interrupts and re-enable only the ones that we are not serving (excluding the already disabled ones too). This will force any other pending interrupt to be triggered and be serviced by a subsequent ISR. This new approach requires, however, changes to the interrupt related pfvf_ops functions. In particular, get_vf2pf_sources() has now been removed in favor of disable_pending_vf2pf_interrupts(), which not only retrieves and returns the pending (and enabled) sources, but also disables them. As a consequence, introduce the adf_disable_pending_vf2pf_interrupts() utility in place of adf_disable_vf2pf_interrupts_irq(), which is no longer needed. Cc: stable@vger.kernel.org Fixes: 993161d ("crypto: qat - fix handling of VF to PF interrupts") Signed-off-by: Marco Chiappero Co-developed-by: Giovanni Cabiddu Signed-off-by: Giovanni Cabiddu Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- drivers/crypto/qat/qat_common/adf_accel_devices.h | 2=20 drivers/crypto/qat/qat_common/adf_gen2_pfvf.c | 58 ++++++++---- drivers/crypto/qat/qat_common/adf_gen4_pfvf.c | 44 +++++++-- drivers/crypto/qat/qat_common/adf_isr.c | 17 +-- drivers/crypto/qat/qat_dh895xcc/adf_dh895xcc_hw_data.c | 76 +++++++++++-= ----- 5 files changed, 132 insertions(+), 65 deletions(-) --- a/drivers/crypto/qat/qat_common/adf_accel_devices.h +++ b/drivers/crypto/qat/qat_common/adf_accel_devices.h @@ -152,9 +152,9 @@ struct adf_pfvf_ops { int (*enable_comms)(struct adf_accel_dev *accel_dev); u32 (*get_pf2vf_offset)(u32 i); u32 (*get_vf2pf_offset)(u32 i); - u32 (*get_vf2pf_sources)(void __iomem *pmisc_addr); void (*enable_vf2pf_interrupts)(void __iomem *pmisc_addr, u32 vf_mask); void (*disable_vf2pf_interrupts)(void __iomem *pmisc_addr, u32 vf_mask); + u32 (*disable_pending_vf2pf_interrupts)(void __iomem *pmisc_addr); int (*send_msg)(struct adf_accel_dev *accel_dev, struct pfvf_message msg, u32 pfvf_offset, struct mutex *csr_lock); struct pfvf_message (*recv_msg)(struct adf_accel_dev *accel_dev, --- a/drivers/crypto/qat/qat_common/adf_gen2_pfvf.c +++ b/drivers/crypto/qat/qat_common/adf_gen2_pfvf.c @@ -13,6 +13,7 @@ #include "adf_pfvf_utils.h" =20 /* VF2PF interrupts */ +#define ADF_GEN2_VF_MSK 0xFFFF #define ADF_GEN2_ERR_REG_VF2PF(vf_src) (((vf_src) & 0x01FFFE00) >> 9) #define ADF_GEN2_ERR_MSK_VF2PF(vf_mask) (((vf_mask) & 0xFFFF) << 9) =20 @@ -50,23 +51,6 @@ static u32 adf_gen2_vf_get_pfvf_offset(u return ADF_GEN2_VF_PF2VF_OFFSET; } =20 -static u32 adf_gen2_get_vf2pf_sources(void __iomem *pmisc_addr) -{ - u32 errsou3, errmsk3, vf_int_mask; - - /* Get the interrupt sources triggered by VFs */ - errsou3 =3D ADF_CSR_RD(pmisc_addr, ADF_GEN2_ERRSOU3); - vf_int_mask =3D ADF_GEN2_ERR_REG_VF2PF(errsou3); - - /* To avoid adding duplicate entries to work queue, clear - * vf_int_mask_sets bits that are already masked in ERRMSK register. - */ - errmsk3 =3D ADF_CSR_RD(pmisc_addr, ADF_GEN2_ERRMSK3); - vf_int_mask &=3D ~ADF_GEN2_ERR_REG_VF2PF(errmsk3); - - return vf_int_mask; -} - static void adf_gen2_enable_vf2pf_interrupts(void __iomem *pmisc_addr, u32 vf_mask) { @@ -89,6 +73,44 @@ static void adf_gen2_disable_vf2pf_inter } } =20 +static u32 adf_gen2_disable_pending_vf2pf_interrupts(void __iomem *pmisc_a= ddr) +{ + u32 sources, disabled, pending; + u32 errsou3, errmsk3; + + /* Get the interrupt sources triggered by VFs */ + errsou3 =3D ADF_CSR_RD(pmisc_addr, ADF_GEN2_ERRSOU3); + sources =3D ADF_GEN2_ERR_REG_VF2PF(errsou3); + + if (!sources) + return 0; + + /* Get the already disabled interrupts */ + errmsk3 =3D ADF_CSR_RD(pmisc_addr, ADF_GEN2_ERRMSK3); + disabled =3D ADF_GEN2_ERR_REG_VF2PF(errmsk3); + + pending =3D sources & ~disabled; + if (!pending) + return 0; + + /* Due to HW limitations, when disabling the interrupts, we can't + * just disable the requested sources, as this would lead to missed + * interrupts if ERRSOU3 changes just before writing to ERRMSK3. + * To work around it, disable all and re-enable only the sources that + * are not in vf_mask and were not already disabled. Re-enabling will + * trigger a new interrupt for the sources that have changed in the + * meantime, if any. + */ + errmsk3 |=3D ADF_GEN2_ERR_MSK_VF2PF(ADF_GEN2_VF_MSK); + ADF_CSR_WR(pmisc_addr, ADF_GEN2_ERRMSK3, errmsk3); + + errmsk3 &=3D ADF_GEN2_ERR_MSK_VF2PF(sources | disabled); + ADF_CSR_WR(pmisc_addr, ADF_GEN2_ERRMSK3, errmsk3); + + /* Return the sources of the (new) interrupt(s) */ + return pending; +} + static u32 gen2_csr_get_int_bit(enum gen2_csr_pos offset) { return ADF_PFVF_INT << offset; @@ -362,9 +384,9 @@ void adf_gen2_init_pf_pfvf_ops(struct ad pfvf_ops->enable_comms =3D adf_enable_pf2vf_comms; pfvf_ops->get_pf2vf_offset =3D adf_gen2_pf_get_pfvf_offset; pfvf_ops->get_vf2pf_offset =3D adf_gen2_pf_get_pfvf_offset; - pfvf_ops->get_vf2pf_sources =3D adf_gen2_get_vf2pf_sources; pfvf_ops->enable_vf2pf_interrupts =3D adf_gen2_enable_vf2pf_interrupts; pfvf_ops->disable_vf2pf_interrupts =3D adf_gen2_disable_vf2pf_interrupts; + pfvf_ops->disable_pending_vf2pf_interrupts =3D adf_gen2_disable_pending_v= f2pf_interrupts; pfvf_ops->send_msg =3D adf_gen2_pf2vf_send; pfvf_ops->recv_msg =3D adf_gen2_vf2pf_recv; } --- a/drivers/crypto/qat/qat_common/adf_gen4_pfvf.c +++ b/drivers/crypto/qat/qat_common/adf_gen4_pfvf.c @@ -15,6 +15,7 @@ /* VF2PF interrupt source registers */ #define ADF_4XXX_VM2PF_SOU 0x41A180 #define ADF_4XXX_VM2PF_MSK 0x41A1C0 +#define ADF_GEN4_VF_MSK 0xFFFF =20 #define ADF_PFVF_GEN4_MSGTYPE_SHIFT 2 #define ADF_PFVF_GEN4_MSGTYPE_MASK 0x3F @@ -36,16 +37,6 @@ static u32 adf_gen4_pf_get_vf2pf_offset( return ADF_4XXX_VM2PF_OFFSET(i); } =20 -static u32 adf_gen4_get_vf2pf_sources(void __iomem *pmisc_addr) -{ - u32 sou, mask; - - sou =3D ADF_CSR_RD(pmisc_addr, ADF_4XXX_VM2PF_SOU); - mask =3D ADF_CSR_RD(pmisc_addr, ADF_4XXX_VM2PF_MSK); - - return sou & ~mask; -} - static void adf_gen4_enable_vf2pf_interrupts(void __iomem *pmisc_addr, u32 vf_mask) { @@ -64,6 +55,37 @@ static void adf_gen4_disable_vf2pf_inter ADF_CSR_WR(pmisc_addr, ADF_4XXX_VM2PF_MSK, val); } =20 +static u32 adf_gen4_disable_pending_vf2pf_interrupts(void __iomem *pmisc_a= ddr) +{ + u32 sources, disabled, pending; + + /* Get the interrupt sources triggered by VFs */ + sources =3D ADF_CSR_RD(pmisc_addr, ADF_4XXX_VM2PF_SOU); + if (!sources) + return 0; + + /* Get the already disabled interrupts */ + disabled =3D ADF_CSR_RD(pmisc_addr, ADF_4XXX_VM2PF_MSK); + + pending =3D sources & ~disabled; + if (!pending) + return 0; + + /* Due to HW limitations, when disabling the interrupts, we can't + * just disable the requested sources, as this would lead to missed + * interrupts if VM2PF_SOU changes just before writing to VM2PF_MSK. + * To work around it, disable all and re-enable only the sources that + * are not in vf_mask and were not already disabled. Re-enabling will + * trigger a new interrupt for the sources that have changed in the + * meantime, if any. + */ + ADF_CSR_WR(pmisc_addr, ADF_4XXX_VM2PF_MSK, ADF_GEN4_VF_MSK); + ADF_CSR_WR(pmisc_addr, ADF_4XXX_VM2PF_MSK, disabled | sources); + + /* Return the sources of the (new) interrupt(s) */ + return pending; +} + static int adf_gen4_pfvf_send(struct adf_accel_dev *accel_dev, struct pfvf_message msg, u32 pfvf_offset, struct mutex *csr_lock) @@ -115,9 +137,9 @@ void adf_gen4_init_pf_pfvf_ops(struct ad pfvf_ops->enable_comms =3D adf_enable_pf2vf_comms; pfvf_ops->get_pf2vf_offset =3D adf_gen4_pf_get_pf2vf_offset; pfvf_ops->get_vf2pf_offset =3D adf_gen4_pf_get_vf2pf_offset; - pfvf_ops->get_vf2pf_sources =3D adf_gen4_get_vf2pf_sources; pfvf_ops->enable_vf2pf_interrupts =3D adf_gen4_enable_vf2pf_interrupts; pfvf_ops->disable_vf2pf_interrupts =3D adf_gen4_disable_vf2pf_interrupts; + pfvf_ops->disable_pending_vf2pf_interrupts =3D adf_gen4_disable_pending_v= f2pf_interrupts; pfvf_ops->send_msg =3D adf_gen4_pfvf_send; pfvf_ops->recv_msg =3D adf_gen4_pfvf_recv; } --- a/drivers/crypto/qat/qat_common/adf_isr.c +++ b/drivers/crypto/qat/qat_common/adf_isr.c @@ -76,32 +76,29 @@ void adf_disable_vf2pf_interrupts(struct spin_unlock_irqrestore(&accel_dev->pf.vf2pf_ints_lock, flags); } =20 -static void adf_disable_vf2pf_interrupts_irq(struct adf_accel_dev *accel_d= ev, - u32 vf_mask) +static u32 adf_disable_pending_vf2pf_interrupts(struct adf_accel_dev *acce= l_dev) { void __iomem *pmisc_addr =3D adf_get_pmisc_base(accel_dev); + u32 pending; =20 spin_lock(&accel_dev->pf.vf2pf_ints_lock); - GET_PFVF_OPS(accel_dev)->disable_vf2pf_interrupts(pmisc_addr, vf_mask); + pending =3D GET_PFVF_OPS(accel_dev)->disable_pending_vf2pf_interrupts(pmi= sc_addr); spin_unlock(&accel_dev->pf.vf2pf_ints_lock); + + return pending; } =20 static bool adf_handle_vf2pf_int(struct adf_accel_dev *accel_dev) { - void __iomem *pmisc_addr =3D adf_get_pmisc_base(accel_dev); bool irq_handled =3D false; unsigned long vf_mask; =20 - /* Get the interrupt sources triggered by VFs */ - vf_mask =3D GET_PFVF_OPS(accel_dev)->get_vf2pf_sources(pmisc_addr); - + /* Get the interrupt sources triggered by VFs, except for those already d= isabled */ + vf_mask =3D adf_disable_pending_vf2pf_interrupts(accel_dev); if (vf_mask) { struct adf_accel_vf_info *vf_info; int i; =20 - /* Disable VF2PF interrupts for VFs with pending ints */ - adf_disable_vf2pf_interrupts_irq(accel_dev, vf_mask); - /* * Handle VF2PF interrupt unless the VF is malicious and * is attempting to flood the host OS with VF2PF interrupts. --- a/drivers/crypto/qat/qat_dh895xcc/adf_dh895xcc_hw_data.c +++ b/drivers/crypto/qat/qat_dh895xcc/adf_dh895xcc_hw_data.c @@ -7,6 +7,8 @@ #include "adf_dh895xcc_hw_data.h" #include "icp_qat_hw.h" =20 +#define ADF_DH895XCC_VF_MSK 0xFFFFFFFF + /* Worker thread to service arbiter mappings */ static const u32 thrd_to_arb_map[ADF_DH895XCC_MAX_ACCELENGINES] =3D { 0x12222AAA, 0x11666666, 0x12222AAA, 0x11666666, @@ -114,29 +116,6 @@ static void adf_enable_ints(struct adf_a ADF_DH895XCC_SMIA1_MASK); } =20 -static u32 get_vf2pf_sources(void __iomem *pmisc_bar) -{ - u32 errsou3, errmsk3, errsou5, errmsk5, vf_int_mask; - - /* Get the interrupt sources triggered by VFs */ - errsou3 =3D ADF_CSR_RD(pmisc_bar, ADF_GEN2_ERRSOU3); - vf_int_mask =3D ADF_DH895XCC_ERR_REG_VF2PF_L(errsou3); - - /* To avoid adding duplicate entries to work queue, clear - * vf_int_mask_sets bits that are already masked in ERRMSK register. - */ - errmsk3 =3D ADF_CSR_RD(pmisc_bar, ADF_GEN2_ERRMSK3); - vf_int_mask &=3D ~ADF_DH895XCC_ERR_REG_VF2PF_L(errmsk3); - - /* Do the same for ERRSOU5 */ - errsou5 =3D ADF_CSR_RD(pmisc_bar, ADF_GEN2_ERRSOU5); - errmsk5 =3D ADF_CSR_RD(pmisc_bar, ADF_GEN2_ERRMSK5); - vf_int_mask |=3D ADF_DH895XCC_ERR_REG_VF2PF_U(errsou5); - vf_int_mask &=3D ~ADF_DH895XCC_ERR_REG_VF2PF_U(errmsk5); - - return vf_int_mask; -} - static void enable_vf2pf_interrupts(void __iomem *pmisc_addr, u32 vf_mask) { /* Enable VF2PF Messaging Ints - VFs 0 through 15 per vf_mask[15:0] */ @@ -150,7 +129,6 @@ static void enable_vf2pf_interrupts(void if (vf_mask >> 16) { u32 val =3D ADF_CSR_RD(pmisc_addr, ADF_GEN2_ERRMSK5) & ~ADF_DH895XCC_ERR_MSK_VF2PF_U(vf_mask); - ADF_CSR_WR(pmisc_addr, ADF_GEN2_ERRMSK5, val); } } @@ -173,6 +151,54 @@ static void disable_vf2pf_interrupts(voi } } =20 +static u32 disable_pending_vf2pf_interrupts(void __iomem *pmisc_addr) +{ + u32 sources, pending, disabled; + u32 errsou3, errmsk3; + u32 errsou5, errmsk5; + + /* Get the interrupt sources triggered by VFs */ + errsou3 =3D ADF_CSR_RD(pmisc_addr, ADF_GEN2_ERRSOU3); + errsou5 =3D ADF_CSR_RD(pmisc_addr, ADF_GEN2_ERRSOU5); + sources =3D ADF_DH895XCC_ERR_REG_VF2PF_L(errsou3) + | ADF_DH895XCC_ERR_REG_VF2PF_U(errsou5); + + if (!sources) + return 0; + + /* Get the already disabled interrupts */ + errmsk3 =3D ADF_CSR_RD(pmisc_addr, ADF_GEN2_ERRMSK3); + errmsk5 =3D ADF_CSR_RD(pmisc_addr, ADF_GEN2_ERRMSK5); + disabled =3D ADF_DH895XCC_ERR_REG_VF2PF_L(errmsk3) + | ADF_DH895XCC_ERR_REG_VF2PF_U(errmsk5); + + pending =3D sources & ~disabled; + if (!pending) + return 0; + + /* Due to HW limitations, when disabling the interrupts, we can't + * just disable the requested sources, as this would lead to missed + * interrupts if sources changes just before writing to ERRMSK3 and + * ERRMSK5. + * To work around it, disable all and re-enable only the sources that + * are not in vf_mask and were not already disabled. Re-enabling will + * trigger a new interrupt for the sources that have changed in the + * meantime, if any. + */ + errmsk3 |=3D ADF_DH895XCC_ERR_MSK_VF2PF_L(ADF_DH895XCC_VF_MSK); + errmsk5 |=3D ADF_DH895XCC_ERR_MSK_VF2PF_U(ADF_DH895XCC_VF_MSK); + ADF_CSR_WR(pmisc_addr, ADF_GEN2_ERRMSK3, errmsk3); + ADF_CSR_WR(pmisc_addr, ADF_GEN2_ERRMSK5, errmsk5); + + errmsk3 &=3D ADF_DH895XCC_ERR_MSK_VF2PF_L(sources | disabled); + errmsk5 &=3D ADF_DH895XCC_ERR_MSK_VF2PF_U(sources | disabled); + ADF_CSR_WR(pmisc_addr, ADF_GEN2_ERRMSK3, errmsk3); + ADF_CSR_WR(pmisc_addr, ADF_GEN2_ERRMSK5, errmsk5); + + /* Return the sources of the (new) interrupt(s) */ + return pending; +} + static void configure_iov_threads(struct adf_accel_dev *accel_dev, bool en= able) { adf_gen2_cfg_iov_thds(accel_dev, enable, @@ -220,9 +246,9 @@ void adf_init_hw_data_dh895xcc(struct ad hw_data->disable_iov =3D adf_disable_sriov; =20 adf_gen2_init_pf_pfvf_ops(&hw_data->pfvf_ops); - hw_data->pfvf_ops.get_vf2pf_sources =3D get_vf2pf_sources; hw_data->pfvf_ops.enable_vf2pf_interrupts =3D enable_vf2pf_interrupts; hw_data->pfvf_ops.disable_vf2pf_interrupts =3D disable_vf2pf_interrupts; + hw_data->pfvf_ops.disable_pending_vf2pf_interrupts =3D disable_pending_vf= 2pf_interrupts; adf_gen2_init_hw_csr_ops(&hw_data->csr_ops); } From nobody Tue Apr 28 06:30:16 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 A5647CCA47C for ; Fri, 3 Jun 2022 18:16:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348550AbiFCSQr (ORCPT ); Fri, 3 Jun 2022 14:16:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40996 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346880AbiFCSF3 (ORCPT ); Fri, 3 Jun 2022 14:05:29 -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 6DA5D5A17B; Fri, 3 Jun 2022 10:58:17 -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 136A1B82433; Fri, 3 Jun 2022 17:57:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 73379C385A9; Fri, 3 Jun 2022 17:57:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279039; bh=GKoL9+gfFzoAe2lfmV6JssBgfwtDzDbaPLiAC/jmV64=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=gcwTQmEpBRCOmMJxa+664THpcdA8DF1rjdZQUKmRgCvsLgvdpjTvxZ0OGn8jdiSCL nxu10jtphQlGsJF7DtDjT2lDFa6ElC4lCbz0UWziDJpOtg9vMUsiK0j0J6HOHhmGAc FtF8ryvMBPoirCkoMYIYCJ0OTLJSVtptZZrm7KBk= 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.18 32/67] zsmalloc: fix races between asynchronous zspage free and page migration Date: Fri, 3 Jun 2022 19:43:33 +0200 Message-Id: <20220603173821.646368850@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- mm/zsmalloc.c | 37 +++++++++++++++++++++++++++++++++---- 1 file changed, 33 insertions(+), 4 deletions(-) --- a/mm/zsmalloc.c +++ b/mm/zsmalloc.c @@ -1718,11 +1718,40 @@ static enum fullness_group putback_zspag */ static void lock_zspage(struct zspage *zspage) { - struct page *page =3D get_first_page(zspage); + struct page *curr_page, *page; =20 - do { - lock_page(page); - } while ((page =3D get_next_page(page)) !=3D NULL); + /* + * Pages we haven't locked yet can be migrated off the list while we're + * trying to lock them, so we need to be careful and only attempt to + * lock each page under migrate_read_lock(). Otherwise, the page we lock + * may no longer belong to the zspage. This means that we may wait for + * the wrong page to unlock, so we must take a reference to the page + * prior to waiting for it to unlock outside migrate_read_lock(). + */ + while (1) { + migrate_read_lock(zspage); + page =3D get_first_page(zspage); + if (trylock_page(page)) + break; + get_page(page); + migrate_read_unlock(zspage); + wait_on_page_locked(page); + put_page(page); + } + + curr_page =3D page; + while ((page =3D get_next_page(curr_page))) { + if (trylock_page(page)) { + curr_page =3D page; + } else { + get_page(page); + migrate_read_unlock(zspage); + wait_on_page_locked(page); + put_page(page); + migrate_read_lock(zspage); + } + } + migrate_read_unlock(zspage); } =20 static int zs_init_fs_context(struct fs_context *fc) From nobody Tue Apr 28 06:30:16 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 8E8BEC433EF for ; Fri, 3 Jun 2022 18:16:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348481AbiFCSQo (ORCPT ); Fri, 3 Jun 2022 14:16:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37854 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346752AbiFCSFJ (ORCPT ); Fri, 3 Jun 2022 14:05:09 -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 0EFB4220EB; Fri, 3 Jun 2022 10:58: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 1C19CB82419; Fri, 3 Jun 2022 17:57:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 78F5AC385A9; Fri, 3 Jun 2022 17:57:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279042; bh=MYuJiGbzxHLG00EokNeFrogd4ykMEO+gtN0yNPcLYSs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=yrio+d8uWyhJGjb2gWLmScok5oQ1Ss7SEc5//lbdQWjHBPH/aRTc/iT+mIMHbeVLe kkzW826TV0P1JIp92rjBaV2YxY6G9zEEfACO0jMBeytyrg/osVgzUrfFLM/KmaGUbg bAAAegVkbMO7wHnQSBM2MPXN63d4LebO6ALElTDU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Akira Yokosawa , Luc Maranget , Jade Alglave , "Paul E. McKenney" Subject: [PATCH 5.18 33/67] tools/memory-model/README: Update klitmus7 compat table Date: Fri, 3 Jun 2022 19:43:34 +0200 Message-Id: <20220603173821.674327165@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 5b759db44195bb779828a188bad6b745c18dcd55 upstream. EXPORT_SYMBOL of do_exec() was removed in v5.17. Unfortunately, kernel modules from klitmus7 7.56 have do_exec() at the end of each kthread. herdtools7 7.56.1 has addressed the issue. Update the compatibility table accordingly. Signed-off-by: Akira Yokosawa Cc: Luc Maranget Cc: Jade Alglave Cc: stable@vger.kernel.org # v5.17+ Signed-off-by: Paul E. McKenney Signed-off-by: Greg Kroah-Hartman Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- tools/memory-model/README | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/tools/memory-model/README +++ b/tools/memory-model/README @@ -54,7 +54,8 @@ klitmus7 Compatibility Table -- 4.14 7.48 -- 4.15 -- 4.19 7.49 -- 4.20 -- 5.5 7.54 -- - 5.6 -- 7.56 -- + 5.6 -- 5.16 7.56 -- + 5.17 -- 7.56.1 -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From nobody Tue Apr 28 06:30:16 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 9C0BAC433EF for ; Fri, 3 Jun 2022 18:17:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344659AbiFCSRI (ORCPT ); Fri, 3 Jun 2022 14:17:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44602 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347073AbiFCSFh (ORCPT ); Fri, 3 Jun 2022 14:05:37 -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 EE7935AA4B; Fri, 3 Jun 2022 10:58:29 -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 2507DB82369; Fri, 3 Jun 2022 17:57:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 778F2C385A9; Fri, 3 Jun 2022 17:57:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279045; bh=u3IpJg7f52QEmZoiTs+geEPRmnLMhe+3HVFYgwUxjcA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=pgxBmK6OvcfIDrtfeaKc7iPNMrHTrQyPaI2akW8EDifMtdKauxiu4vJlCIH9e2YAL hevDK/zhstJ401OPjtmrQpSnG7rUYQjz5ke9sRM3uL2PKzHiACI9QL4ez64jDwa9Aq 1LLVkJWZW885XhdGMVnnbhQ1me6CUdxwZPCh+8l4= 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.18 34/67] ALSA: usb-audio: Workaround for clock setup on TEAC devices Date: Fri, 3 Jun 2022 19:43:35 +0200 Message-Id: <20220603173821.703724527@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- 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 Tue Apr 28 06:30:16 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 3C76ACCA473 for ; Fri, 3 Jun 2022 18:16:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348396AbiFCSQi (ORCPT ); Fri, 3 Jun 2022 14:16:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44876 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346729AbiFCSFH (ORCPT ); Fri, 3 Jun 2022 14:05:07 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4352122B2C; Fri, 3 Jun 2022 10:58: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 dfw.source.kernel.org (Postfix) with ESMTPS id 83F12615E3; Fri, 3 Jun 2022 17:57:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 75AF5C385B8; Fri, 3 Jun 2022 17:57:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279048; bh=k8dwY4UsBqEZIeUNq0npNOB1aRN/HTu4O5GznizTuIE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RXNmc5cVJZwLxupz1V1v7oLjo3Zcjc8ZhVFD90F27bedTjopSsZvOb2+vU0bjXItM KeiodrPY4Qu06JR4UAxi7pee6rcw+jfQy9+/iLgBIjq8ST16kcV1VIAK+MBdgoL6iO kTT3kzGgIZRds5tepgEgq7yGsTt9pSHEgbuU+J3I= 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.18 35/67] ALSA: usb-audio: Add missing ep_idx in fixed EP quirks Date: Fri, 3 Jun 2022 19:43:36 +0200 Message-Id: <20220603173821.742858262@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- 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 Tue Apr 28 06:30:16 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 B763CC43334 for ; Fri, 3 Jun 2022 18:19:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230426AbiFCSTD (ORCPT ); Fri, 3 Jun 2022 14:19:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48162 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348054AbiFCSGg (ORCPT ); Fri, 3 Jun 2022 14:06:36 -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 E75715DBCC; Fri, 3 Jun 2022 10:59:44 -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 E2BC3615D3; Fri, 3 Jun 2022 17:59:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CA56DC385A9; Fri, 3 Jun 2022 17:59:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279170; bh=rsXX6yLeIHVO6O+swiWLs088Z3L8fZkQ83Rdgo4SA0M=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=QFKXIQx1Ua/JRtkZ3tqrr7yao/B5s7ZRUTSZsSbS46QNyADWT5UDvak2SvgDTGiSl mAVFaTqFpS/tjvGQd8ZqkQNgI8YXOj7q9UtnH+niZRFxmrX0vniaIyn1iGY7wSy3H2 0QzcBKucLw1asICGWq6NYrnJ/KT1Wg+RV01gPz7s= 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.18 36/67] ALSA: usb-audio: Configure sync endpoints before data Date: Fri, 3 Jun 2022 19:43:37 +0200 Message-Id: <20220603173821.777889348@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- sound/usb/pcm.c | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) --- a/sound/usb/pcm.c +++ b/sound/usb/pcm.c @@ -439,16 +439,21 @@ static int configure_endpoints(struct sn /* 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; From nobody Tue Apr 28 06:30:16 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 7CF50C43334 for ; Fri, 3 Jun 2022 18:21:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347543AbiFCSUo (ORCPT ); Fri, 3 Jun 2022 14:20:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44984 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347238AbiFCSFp (ORCPT ); Fri, 3 Jun 2022 14:05:45 -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 E7EA55B3CE; Fri, 3 Jun 2022 10:58:41 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 8F9A4B82439; Fri, 3 Jun 2022 17:57:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A3FDCC36AF6; Fri, 3 Jun 2022 17:57:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279074; bh=tfgjU31NPL+z9713wFziaUtlFoPM/QCEwzK8ujtven8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=g5DaVsjK3n/xgcMrkgHjGQUGkRz33JML5l/hz2I56QOYPFLRAsbjvc82kcZfyoenR dzdJpFOH2+qf+lWobQ3ue38x2wM5UwwAS+1jzxor7xzkkPoRQ8T8Ee451QlO8+00Jp DZzIqH54YiCeK/kt08ttRqNzGRVS/DnkzNuLN3hQ= 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.18 37/67] Bluetooth: hci_qca: Use del_timer_sync() before freeing Date: Fri, 3 Jun 2022 19:43:38 +0200 Message-Id: <20220603173821.805225818@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- 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 Tue Apr 28 06:30:16 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 65F6DC43334 for ; Fri, 3 Jun 2022 18:18:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242711AbiFCSR7 (ORCPT ); Fri, 3 Jun 2022 14:17:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44876 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347612AbiFCSGK (ORCPT ); Fri, 3 Jun 2022 14:06: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 5393A5C36B; Fri, 3 Jun 2022 10:59: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 B2474615DC; Fri, 3 Jun 2022 17:58:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A5969C385B8; Fri, 3 Jun 2022 17:58:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279108; bh=/EyG57P4jtW4RHdb3WPUV5f8lPpG5g2cOM8KMHmq+5w=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=1OOk30dInFbZVRy0BEhu+havItVlIMowGekN1Fy2acQDW7GyUvBpT0WIeNqd4sQ+Y mPkYQJa8ieEhX4aHCYKn/4ZLnlTBm04SVmIrz3xTvxRAjpqIi38WQv/Remyj2zqPAy 0F+RL3M0tPiUMzzjc2/Jb4IgeHoZzSmg2BCm8QRE= 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.18 38/67] ARM: dts: s5pv210: Correct interrupt name for bluetooth in Aries Date: Fri, 3 Jun 2022 19:43:39 +0200 Message-Id: <20220603173821.833386170@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- 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 Tue Apr 28 06:30:16 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 7FDF0C43334 for ; Fri, 3 Jun 2022 18:19:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347014AbiFCSTr (ORCPT ); Fri, 3 Jun 2022 14:19:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40992 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348060AbiFCSGg (ORCPT ); Fri, 3 Jun 2022 14:06:36 -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 1DD7D5DD3A; Fri, 3 Jun 2022 10:59:44 -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 44F066158E; Fri, 3 Jun 2022 17:59:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 43D1FC385A9; Fri, 3 Jun 2022 17:59:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279142; bh=jRo0E2UCuPCv1JfLpdMudZFaAv6Om2hSVnmaYr/kXRk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Qk5IaJhIWTzVXOVE2jLUKzcnSV4GQOLRO03A1ROtGXU9ukoPnQnn62c3zcZOe4jTz Io9jgAAw8MmoZxfAux5GRtPzbq/o+Y/YEx+rMG9TvfdLXcI0+Ooox1NGDk+2D4cfD2 wFbE180SaaSQM7vCLAWe2lu16bVZKZsgLHzhY6bw= 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.18 39/67] dm integrity: fix error code in dm_integrity_ctr() Date: Fri, 3 Jun 2022 19:43:40 +0200 Message-Id: <20220603173821.860340294@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- drivers/md/dm-integrity.c | 2 -- 1 file changed, 2 deletions(-) --- a/drivers/md/dm-integrity.c +++ b/drivers/md/dm-integrity.c @@ -4494,8 +4494,6 @@ try_smaller_buffer: } =20 if (should_write_sb) { - int r; - init_journal(ic, 0, ic->journal_sections, 0); r =3D dm_integrity_failed(ic); if (unlikely(r)) { From nobody Tue Apr 28 06:30:16 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 46C8CC43334 for ; Fri, 3 Jun 2022 18:18:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346000AbiFCSST (ORCPT ); Fri, 3 Jun 2022 14:18:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44880 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347621AbiFCSGK (ORCPT ); Fri, 3 Jun 2022 14:06: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 D5C6A5C668; Fri, 3 Jun 2022 10:59: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 dfw.source.kernel.org (Postfix) with ESMTPS id 97ED161244; Fri, 3 Jun 2022 17:59:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 966C9C385A9; Fri, 3 Jun 2022 17:59:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279152; bh=zNBriAybDk2IYMCrYLDMQmf+Q0OdY4Eg8wnW7cnhBSw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=TYRd9Wj9k8Yit1iGwy9nXhhCLNOvwSqoI6v90trB1aSzGXYlA80tQPzY4BKkbiL2B Fv+FbtIfk5yevSN/OV+/0+g4wzzAftWn0yVXKSy/+7kTOUCVgbL5CZPFgGSSaXAgmU /4izC0y+1DYt4+o8pnWvJp6iruTnoRk3Q679ezj8= 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.18 40/67] dm crypt: make printing of the key constant-time Date: Fri, 3 Jun 2022 19:43:41 +0200 Message-Id: <20220603173821.888219448@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- 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 @@ -3439,6 +3439,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) { @@ -3457,9 +3462,12 @@ static void crypt_status(struct dm_targe if (cc->key_size > 0) { if (cc->key_string) DMEMIT(":%u:%s", cc->key_size, cc->key_string); - else - for (i =3D 0; i < cc->key_size; i++) - DMEMIT("%02x", cc->key[i]); + else { + for (i =3D 0; i < cc->key_size; i++) { + DMEMIT("%c%c", hex2asc(cc->key[i] >> 4), + hex2asc(cc->key[i] & 0xf)); + } + } } else DMEMIT("-"); From nobody Tue Apr 28 06:30:16 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 F41C6C433EF for ; Fri, 3 Jun 2022 18:19:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346597AbiFCST1 (ORCPT ); Fri, 3 Jun 2022 14:19:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40994 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347673AbiFCSGN (ORCPT ); Fri, 3 Jun 2022 14:06:13 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 508115C34A; Fri, 3 Jun 2022 10:59: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 BF75160F3B; Fri, 3 Jun 2022 17:59:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D6425C385A9; Fri, 3 Jun 2022 17:59:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279155; bh=8Zu7MjpXWW9lQAoYnVgd0XW5X1hTwM+Sak8w4dzHC0g=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=bKI9QZGe7CVbUVo07XSIt1E/mhigQqatvXKuvJ5PcjJ+MhbDhxSooeRx6umnml46n a52eVGi8rBr1yAIcLVAhHwrIdlyBZwqvuqIXfOZPGFrwFswGmwFm8y8lMj0kTA4Cjw 346E9ppK/DFvTsyvezksQTlI3W1fQAfUxxSXIwEg= 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.18 41/67] dm stats: add cond_resched when looping over entries Date: Fri, 3 Jun 2022 19:43:42 +0200 Message-Id: <20220603173821.915659056@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- 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 Tue Apr 28 06:30:16 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 88AB1C43334 for ; Fri, 3 Jun 2022 18:19:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347055AbiFCSTJ (ORCPT ); Fri, 3 Jun 2022 14:19:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56430 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348132AbiFCSGk (ORCPT ); Fri, 3 Jun 2022 14:06:40 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B6B625E746; Fri, 3 Jun 2022 10:59: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 ams.source.kernel.org (Postfix) with ESMTPS id 871AAB8241E; Fri, 3 Jun 2022 17:59:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CBB68C385A9; Fri, 3 Jun 2022 17:59:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279158; bh=TNIMVPaeLJ/QcWDFFqjeA42a5Y4yMf8PXuFOQY86fbU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=i6+UPWMV0+kiUfEI3zi4JMm560h9Xm/IjmKkM9L4mEv6iroeaJ76n0d985SZ+GUQs gXt1EmK29hjO83WiKWw5whnvlDiLxBI5WrUkOWYxnxUPovcRmaevsyWnP66wZ64AuT 2o47gun5VmVvZT2VbR/s5MDIej0+aBozaq2EUj4Q= 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.18 42/67] dm verity: set DM_TARGET_IMMUTABLE feature flag Date: Fri, 3 Jun 2022 19:43:43 +0200 Message-Id: <20220603173821.944489394@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- 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 Tue Apr 28 06:30:16 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 B4996C43334 for ; Fri, 3 Jun 2022 18:18:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346999AbiFCSSq (ORCPT ); Fri, 3 Jun 2022 14:18:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56886 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347760AbiFCSGQ (ORCPT ); Fri, 3 Jun 2022 14:06:16 -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 25C985D191; Fri, 3 Jun 2022 10:59:22 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id D75AB615DC; Fri, 3 Jun 2022 17:59:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D2AE7C385A9; Fri, 3 Jun 2022 17:59:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279161; bh=IwMXpPmhG/dea4cxYNoFXCkP+pmzqAVA+KCbV9LIOJk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=L0jwKP8F0RKr9YCK7/pr0wuzxax0c2udteS0pWnyOeFvtUAp+JF3mk2XmvslEmvGI xIODXQtWXAZOYAlpQneOcJWlOBVY9lnnMCpnzk9o6K/KColNK2ALKH/U1oEKFe4+4H BFrDHMpJOxtZhz7fGhc3daaiLJJ9/nci3EHGQaDk= 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.18 43/67] raid5: introduce MD_BROKEN Date: Fri, 3 Jun 2022 19:43:44 +0200 Message-Id: <20220603173821.972554527@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- 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 * @@ -2863,34 +2863,31 @@ static void raid5_error(struct mddev *md unsigned long flags; pr_debug("raid456: error called\n"); =20 + pr_crit("md/raid:%s: Disk failure on %s, disabling device.\n", + mdname(mddev), bdevname(rdev->bdev, b)); + spin_lock_irqsave(&conf->device_lock, flags); + set_bit(Faulty, &rdev->flags); + clear_bit(In_sync, &rdev->flags); + mddev->degraded =3D raid5_calc_degraded(conf); =20 - if (test_bit(In_sync, &rdev->flags) && - mddev->degraded =3D=3D conf->max_degraded) { - /* - * Don't allow to achieve failed state - * Don't try to recover this device - */ + if (has_failed(conf)) { + set_bit(MD_BROKEN, &conf->mddev->flags); conf->recovery_disabled =3D mddev->recovery_disabled; - spin_unlock_irqrestore(&conf->device_lock, flags); - return; + + pr_crit("md/raid:%s: Cannot continue operation (%d/%d failed).\n", + mdname(mddev), mddev->degraded, conf->raid_disks); + } else { + pr_crit("md/raid:%s: Operation continuing on %d devices.\n", + mdname(mddev), conf->raid_disks - mddev->degraded); } =20 - set_bit(Faulty, &rdev->flags); - clear_bit(In_sync, &rdev->flags); - mddev->degraded =3D raid5_calc_degraded(conf); spin_unlock_irqrestore(&conf->device_lock, flags); set_bit(MD_RECOVERY_INTR, &mddev->recovery); =20 set_bit(Blocked, &rdev->flags); set_mask_bits(&mddev->sb_flags, 0, BIT(MD_SB_CHANGE_DEVS) | BIT(MD_SB_CHANGE_PENDING)); - pr_crit("md/raid:%s: Disk failure on %s, disabling device.\n" - "md/raid:%s: Operation continuing on %d devices.\n", - mdname(mddev), - bdevname(rdev->bdev, b), - mdname(mddev), - conf->raid_disks - mddev->degraded); r5c_update_on_rdev_error(mddev, rdev); } From nobody Tue Apr 28 06:30:16 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 73B69C43334 for ; Fri, 3 Jun 2022 18:19:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238967AbiFCSTe (ORCPT ); Fri, 3 Jun 2022 14:19:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56444 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347869AbiFCSG0 (ORCPT ); Fri, 3 Jun 2022 14:06:26 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ED1E65D5E0; Fri, 3 Jun 2022 10:59: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 B10D861555; Fri, 3 Jun 2022 17:59:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8F920C385B8; Fri, 3 Jun 2022 17:59:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279164; bh=EPBHgmukQQ2kavRRx6NFY8j/vcnjOWl5lgESjAPm9W8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=K+FdT5wmZQycc4wxKQp06QjZZcm45uvmVM52PdQuFqZP9+RLoMAQfr+wB+h6EqQlA WiaXBprIzeBjOAW0GSNcZao5YHAxIYwjsaYdBB5SmlrgeI7hj2ntlJ6qeXCPGS89R9 xiPlEp8793XGDjR1VomIBEfEGbqih/gm9lPil1SA= 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.18 44/67] fs/ntfs3: validate BOOT sectors_per_clusters Date: Fri, 3 Jun 2022 19:43:45 +0200 Message-Id: <20220603173822.000588901@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- 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 Tue Apr 28 06:30:16 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 D4646C43334 for ; Fri, 3 Jun 2022 18:19:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346320AbiFCSTS (ORCPT ); Fri, 3 Jun 2022 14:19:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47032 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348331AbiFCSGv (ORCPT ); Fri, 3 Jun 2022 14:06:51 -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 0E65933A32; Fri, 3 Jun 2022 11:00: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 C37F961244; Fri, 3 Jun 2022 17:59:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D1775C341C0; Fri, 3 Jun 2022 17:59:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279167; bh=LQ4GAiIPoecpW2UvZsPu+mR5D6ND/oIWgjWyJt1PfTM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=g1OgZjPE0j2HNLvcET7k9d5tD3sp7tD9L1yx/rFj7BoLJD5t38U9ef+HZT7fuKZy0 Kxivmg+waij3ic4Mz4dPRGBzL24LLlHs/j3Ef6gTZBVsYDQCDhqBjG3QrGR8HgIRkZ Lns7GgtUXMIJETqSx1a4yKyu8dINKh5Edx9/Z7+g= 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.18 45/67] HID: multitouch: Add support for Google Whiskers Touchpad Date: Fri, 3 Jun 2022 19:43:46 +0200 Message-Id: <20220603173822.028442636@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- drivers/hid/hid-multitouch.c | 3 +++ 1 file changed, 3 insertions(+) --- a/drivers/hid/hid-multitouch.c +++ b/drivers/hid/hid-multitouch.c @@ -2178,6 +2178,9 @@ static const struct hid_device_id mt_dev { .driver_data =3D MT_CLS_GOOGLE, HID_DEVICE(HID_BUS_ANY, HID_GROUP_ANY, USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_TOUCH_ROSE) }, + { .driver_data =3D MT_CLS_GOOGLE, + HID_DEVICE(BUS_USB, HID_GROUP_MULTITOUCH_WIN_8, USB_VENDOR_ID_GOOGLE, + USB_DEVICE_ID_GOOGLE_WHISKERS) }, =20 /* Generic MT device */ { HID_DEVICE(HID_BUS_ANY, HID_GROUP_MULTITOUCH, HID_ANY_ID, HID_ANY_ID) }, From nobody Tue Apr 28 06:30:16 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 C8439C433EF for ; Fri, 3 Jun 2022 18:18:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235610AbiFCSSF (ORCPT ); Fri, 3 Jun 2022 14:18:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46896 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347549AbiFCSGH (ORCPT ); Fri, 3 Jun 2022 14:06:07 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 45C5F579AE; Fri, 3 Jun 2022 10:59: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 1CEFA615D3; Fri, 3 Jun 2022 17:57:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 24C63C385B8; Fri, 3 Jun 2022 17:57:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279077; bh=Z9HEECr0VtFPJXA25d0AXB9GxZ1MtBabqEX39UsEs4E=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=x3FHnyJuGiLwIbdURfc5H+rauuh4YBuWMa+GOszKLYUluiP95lxh4gboMBLiNO+5U ku2KyjJsG0jMy2muUoD0GcqGBcL1/rLgeg8RrsLJsC0tFDWCzJHtxTywiJrtovGaB8 1L9g4ztlt4wK99iTPeP/SaAgPqJoYY4nxalUXY1U= 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.18 46/67] HID: multitouch: add quirks to enable Lenovo X12 trackpoint Date: Fri, 3 Jun 2022 19:43:47 +0200 Message-Id: <20220603173822.057799620@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- 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 @@ -768,6 +768,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 @@ -2034,6 +2034,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 Tue Apr 28 06:30:16 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 7DDDEC433EF for ; Fri, 3 Jun 2022 18:17:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346102AbiFCSRm (ORCPT ); Fri, 3 Jun 2022 14:17:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46364 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347533AbiFCSGG (ORCPT ); Fri, 3 Jun 2022 14:06:06 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1DFE35C341; Fri, 3 Jun 2022 10:59: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 1303161244; Fri, 3 Jun 2022 17:58:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 191DCC385A9; Fri, 3 Jun 2022 17:57:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279080; bh=HguISO7OMQMK/aMjsZvenlvTT/seMK7a2DTlQSbRj9U=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=NzB+5AAgmmE8KZe7/xtXIy8APOWeSdMwDK5vpIMUOIR+sdOnIaeyYFI5g0ISZj1YC DVEHGPoQtIoiG+N0j507qeqC9TYSTej5WiHZ4eD4XMdxa0TJKzSpkEclSfx8p88txs BwvJtK8hNssvpMy4FQOCyztDQ17egGWxkN1QpJwg= 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.18 47/67] x86/sgx: Disconnect backing page references from dirty status Date: Fri, 3 Jun 2022 19:43:48 +0200 Message-Id: <20220603173822.086210480@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- 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 @@ -191,6 +191,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)); @@ -320,7 +322,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: @@ -411,7 +413,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 Tue Apr 28 06:30:16 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 19A26C43334 for ; Fri, 3 Jun 2022 18:18:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346673AbiFCSSc (ORCPT ); Fri, 3 Jun 2022 14:18:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44874 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347720AbiFCSGO (ORCPT ); Fri, 3 Jun 2022 14:06:14 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D95955D1AB; Fri, 3 Jun 2022 10:59:22 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 52537615DA; Fri, 3 Jun 2022 17:58:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 48B5FC385A9; Fri, 3 Jun 2022 17:58:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279083; bh=jRGYaec2MuAtdgELoc6FWEItHG4GgkCI+meBt12+l9A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=gsrkXD4kjOcfLxqzJp5E/O0swCCGzx2AFpV/Rrpm86BtjUMxz5eiIM4qsexG1kIY3 ULAGv8k6J4KrN2WeD+zZxEFJAAjgWwzQwYAuksx0j9nY7k/oU957H/WmW+0iBEJfIU wSnxiptXFDQacP7xZg1Mm2qNXQ9ZvlVLymZSiC7I= 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.18 48/67] x86/sgx: Mark PCMD page as dirty when modifying contents Date: Fri, 3 Jun 2022 19:43:49 +0200 Message-Id: <20220603173822.114047536@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- 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 Tue Apr 28 06:30:16 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 1C74ACCA473 for ; Fri, 3 Jun 2022 18:22:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348005AbiFCSVw (ORCPT ); Fri, 3 Jun 2022 14:21:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33182 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347757AbiFCSP6 (ORCPT ); Fri, 3 Jun 2022 14:15:58 -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 42B5C61621; Fri, 3 Jun 2022 11:03: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 63ADA61663; Fri, 3 Jun 2022 17:58:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 57285C3411D; Fri, 3 Jun 2022 17:58:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279086; bh=h63YL1mZsMLVcspF3UHcpRh8yN21n3CyTPYJb1ZQRIg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=t6gYtk1N5WEV0nyLhGi4HEVhImaYtmRwvT8KhwRwMBz4p/s8Hb1TMCEMJb0jHc0S2 y+3+rROhcxQI0iZuDZYoBLcAoFzunXJsKVyR4qlpgFJ4JUwHymhf4uyI2REQ7uXQKh dGW57/l0OElfUSIa/wPpZ8KYot8F7rx45gTrNd48= 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.18 49/67] x86/sgx: Obtain backing storage page with enclave mutex held Date: Fri, 3 Jun 2022 19:43:50 +0200 Message-Id: <20220603173822.141858221@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- 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 @@ -310,6 +310,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), @@ -381,11 +382,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; @@ -413,7 +417,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 Tue Apr 28 06:30:16 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 46A31CCA481 for ; Fri, 3 Jun 2022 18:21:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347416AbiFCSUY (ORCPT ); Fri, 3 Jun 2022 14:20:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48166 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347581AbiFCSGI (ORCPT ); Fri, 3 Jun 2022 14:06: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 29A3E5C35A; Fri, 3 Jun 2022 10:59: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 dfw.source.kernel.org (Postfix) with ESMTPS id 62CB960F3B; Fri, 3 Jun 2022 17:58:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6C285C385A9; Fri, 3 Jun 2022 17:58:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279089; bh=gu/GON9TB219Xl36FcW1sJOa2e8mHgE4PmzKh6ejERI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=u4ibf6qUZQNwS+zdEaM9jGJEi0Z5/zNZhr6SNZ6ZQzC6oBVfRlHMaAmfYxQz7Eoj+ UAk963s8UquixzCJAOZtyb+NEeOoT3KEjZAqwZ9QuaZ9m0MGE0VPJWMw902Xouc9Xj w36ujfYVOmpJxStZzkuKUyq66yGA9GwzFFUjAKnA= 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.18 50/67] x86/sgx: Fix race between reclaimer and page fault handler Date: Fri, 3 Jun 2022 19:43:51 +0200 Message-Id: <20220603173822.171136364@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- 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 Tue Apr 28 06:30:16 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 31578C433EF for ; Fri, 3 Jun 2022 18:17:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344738AbiFCSRU (ORCPT ); Fri, 3 Jun 2022 14:17:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37854 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347109AbiFCSFi (ORCPT ); Fri, 3 Jun 2022 14:05:38 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 784EF275C7; Fri, 3 Jun 2022 10:58: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 8B8766166E; Fri, 3 Jun 2022 17:58:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7CD85C385A9; Fri, 3 Jun 2022 17:58:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279093; bh=DdcTsahpMA3mopHeABHUdvpDhh4i1FgDJdxIWWBmhHc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Gcr4NMsc7dK/zKsFWfZ/QWBPWW4XEJizoJxXpcXY0ci5tngLP952bzzN+Frug2+6Y TNg0QULn3UlMcaX8hYe1f0GW6YL0I/CnMy15q8aoBaoYK2EpKUUsyqlSDrE12fnBZH ihDRYT2uE0uH5KIKUL2SRkO2OCxLKAGw1bQqbj4o= 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.18 51/67] x86/sgx: Ensure no data in PCMD page after truncate Date: Fri, 3 Jun 2022 19:43:52 +0200 Message-Id: <20220603173822.199037809@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- 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 Tue Apr 28 06:30:16 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 D8E6BC433EF for ; Fri, 3 Jun 2022 18:18:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243754AbiFCSRt (ORCPT ); Fri, 3 Jun 2022 14:17:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56430 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347611AbiFCSGK (ORCPT ); Fri, 3 Jun 2022 14:06: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 537A75C36A; Fri, 3 Jun 2022 10:59: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 9956B6165B; Fri, 3 Jun 2022 17:58:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9C409C3411F; Fri, 3 Jun 2022 17:58:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279096; bh=Cd2X9X9D1pUtLT7Y22U/EmbcPT8vW5ZoQ885p5Z6CdU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=x2v4lypfoo81qMJ7lOOa01X7x0YqUvcL/6htIuitQWLc7W/xwFc/Ps/xBs68otxvb LazbucnFvA4ahJ3srDIHcErCDbPAfWqAKvLwmVygQZOklwcec0/1veCaP1QcfOBhiT tdLH5ARYzGM/QlJmkH1Z3BXi6+bcup1ZUaBUfGGw= 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.18 52/67] media: i2c: imx412: Fix reset GPIO polarity Date: Fri, 3 Jun 2022 19:43:53 +0200 Message-Id: <20220603173822.227553579@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- 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 Tue Apr 28 06:30:16 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 14BA1CCA47E for ; Fri, 3 Jun 2022 18:21:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347331AbiFCSUO (ORCPT ); Fri, 3 Jun 2022 14:20:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50600 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347691AbiFCSGN (ORCPT ); Fri, 3 Jun 2022 14:06:13 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BC2DF5C86C; Fri, 3 Jun 2022 10:59: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 A66C56164C; Fri, 3 Jun 2022 17:58:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9D4B5C385A9; Fri, 3 Jun 2022 17:58:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279099; bh=1dDCelCnd3TDU/oKMdf68Nki42Ch/uDP9y6NwwQdRnE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=VY4bn7d9vWGEZ7if+ACqPsiTLaxO3l0P6SKnNKwpr+S4vfkigU6/j0y5CGSHYbW58 p+rbb4TrtpG45WloK2KBXDQIMyRMPz5FR3d1UjKv4EPnGYjgiFGOIvPCmxezXDd1Nq 3xKCFfVT7WpJBdPd+WcyIEHiddL2ZajAIVVQeA1E= 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.18 53/67] media: i2c: imx412: Fix power_off ordering Date: Fri, 3 Jun 2022 19:43:54 +0200 Message-Id: <20220603173822.255099637@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- 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 Tue Apr 28 06:30:16 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 592F9CCA480 for ; Fri, 3 Jun 2022 18:21:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347459AbiFCSU3 (ORCPT ); Fri, 3 Jun 2022 14:20:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47106 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347572AbiFCSGI (ORCPT ); Fri, 3 Jun 2022 14:06:08 -0400 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4218D5C351; Fri, 3 Jun 2022 10:59: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 sin.source.kernel.org (Postfix) with ESMTPS id 99045CE233B; Fri, 3 Jun 2022 17:58:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AACDAC385A9; Fri, 3 Jun 2022 17:58:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279102; bh=yyrGhqI8IVeC53hKFu4TYqVuzOZWCA2X3vdF+q2ZsDc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=xBb7aRenJSYO8Yw6b0fgkLMyFeoxtRTYB6V/fRWe+WXR6kZMnnIuVUWqLk7MmSabI 8yi7Ja5qyuyoP9vtzStjpi2Hr8hda3th+33KqdoZE6Zj4qc33MgMU4k/QNSRFKJBtu erkvSA3+TY2qqEfkhomZCGBlbZp/+b5CJcQiCuNM= 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.18 54/67] tpm: Fix buffer access in tpm2_get_tpm_pt() Date: Fri, 3 Jun 2022 19:43:55 +0200 Message-Id: <20220603173822.282732143@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- 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 Tue Apr 28 06:30:16 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 E9E08C43334 for ; Fri, 3 Jun 2022 18:18:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346722AbiFCSS0 (ORCPT ); Fri, 3 Jun 2022 14:18:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48166 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347701AbiFCSGO (ORCPT ); Fri, 3 Jun 2022 14:06:14 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B180157B04; Fri, 3 Jun 2022 10:59: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 9D992615E3; Fri, 3 Jun 2022 17:58:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A2827C385A9; Fri, 3 Jun 2022 17:58:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279105; bh=x5kV3Z+YxJqaxbkJ5fOTbYmq3aXHfxYboSUuniNqq7c=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=fLbha1diZrIeBhHzRJxxZisok0V3WhjjM4H69YBTbHYRcMUMpNj290LulofIRYH61 EPp8kTLL9Ioct3NzLSk/UoqdGbbtQZxstPlWsJl7RudLLkLy3YwbD7eu7ouUsIL4f3 xKH2nur3/oad9OZeF4a85Ij6N+NX6lt6pLDvgdkk= 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.18 55/67] tpm: ibmvtpm: Correct the return value in tpm_ibmvtpm_probe() Date: Fri, 3 Jun 2022 19:43:56 +0200 Message-Id: <20220603173822.310253682@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- 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 Tue Apr 28 06:30:16 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 3583CCCA47C for ; Fri, 3 Jun 2022 18:21:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347387AbiFCSUQ (ORCPT ); Fri, 3 Jun 2022 14:20:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46838 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347653AbiFCSGL (ORCPT ); Fri, 3 Jun 2022 14:06: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 C193F5C679; Fri, 3 Jun 2022 10:59:13 -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 A461561555; Fri, 3 Jun 2022 17:58:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B006EC385A9; Fri, 3 Jun 2022 17:58:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279111; bh=AcfFm/yHcxVrDDYCPrsFv0Wa5KiA0w+LkOopDm5lkzY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=VeomguvyjrWmSJWH8HdjpzKN+Q2fCOIrEcCFJt9ElV30tNRdhddlvcF5lmtDgvYRh eRM/hoQeLGbwkPCh/zWI8LrZ1Rcpst2Bx5+3SckWHxZwsDe+UItSKqEK9vbbdmF/ds hj+0QNLLQNPnSAWM77RXX5/Kwj4KAPRa6y58HBi4= 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.18 56/67] docs: submitting-patches: Fix crossref to The canonical patch format Date: Fri, 3 Jun 2022 19:43:57 +0200 Message-Id: <20220603173822.337596431@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- 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 @@ -77,7 +77,7 @@ as you intend it to. =20 The maintainer will thank you if you write your patch description in a form which can be easily pulled into Linux's source code management -system, ``git``, as a "commit log". See :ref:`explicit_in_reply_to`. +system, ``git``, as a "commit log". See :ref:`the_canonical_patch_format`. =20 Solve only one problem per patch. If your description starts to get long, that's a sign that you probably need to split up your patch. From nobody Tue Apr 28 06:30:16 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 404C3C43334 for ; Fri, 3 Jun 2022 18:18:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343844AbiFCSSL (ORCPT ); Fri, 3 Jun 2022 14:18:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44904 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347619AbiFCSGK (ORCPT ); Fri, 3 Jun 2022 14:06: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 EAA725C648; Fri, 3 Jun 2022 10:59: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 7293BB82419; Fri, 3 Jun 2022 17:58:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id ADBBCC385A9; Fri, 3 Jun 2022 17:58:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279114; bh=XNeBLSYMPSQjPWmzLH3dmNef5spnlWweGemETuSTW7o=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=TFygasQSINCaWjc8gHWztbbXmDnjgfHy+Tz0i0mwWANwzQL0dsRDzzS1L+wgTpfGt loFphZRh5XiofsCodEnBg1VBUsyjWXlR8BW6xWA0YdsV46slEW8k6byiGAUZgOWxAu oV04FM6RKGg1yQxoR6TdR56+sEhR6n2iyNsXUlps= 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.18 57/67] NFS: Memory allocation failures are not server fatal errors Date: Fri, 3 Jun 2022 19:43:58 +0200 Message-Id: <20220603173822.365946973@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- fs/nfs/internal.h | 1 + 1 file changed, 1 insertion(+) --- a/fs/nfs/internal.h +++ b/fs/nfs/internal.h @@ -841,6 +841,7 @@ static inline bool nfs_error_is_fatal_on case 0: case -ERESTARTSYS: case -EINTR: + case -ENOMEM: return false; } return nfs_error_is_fatal(err); From nobody Tue Apr 28 06:30:16 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 9CA31CCA47C for ; Fri, 3 Jun 2022 18:21:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347619AbiFCSUw (ORCPT ); Fri, 3 Jun 2022 14:20:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36532 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347230AbiFCSFp (ORCPT ); Fri, 3 Jun 2022 14:05: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 251DC5AEFB; Fri, 3 Jun 2022 10:58: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 dfw.source.kernel.org (Postfix) with ESMTPS id B352460F32; Fri, 3 Jun 2022 17:58:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B6834C385A9; Fri, 3 Jun 2022 17:58:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279117; bh=TdDP+Db7xcOWnxSQDmXme3EoRbglcHsVWz0Cb2tdDok=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=2GGiT48c9o8FpYMPtwhYMq4qKLVjbAk6O5NQVmlyKIjGcUtUVynC2+TzH/B5t7aBs DpLw6l9s9TfEZOGVurHNlKlgJZvWEt1XN1o9Q9bzp1Ew7qQcYeWkPoFu8mJAeD5Pih uUNjmsT0UtLmjMTc5awPTto6z6d8l7HxH2O/6uC4= 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.18 58/67] NFSD: Fix possible sleep during nfsd4_release_lockowner() Date: Fri, 3 Jun 2022 19:43:59 +0200 Message-Id: <20220603173822.393586749@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- fs/nfsd/nfs4state.c | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) --- a/fs/nfsd/nfs4state.c +++ b/fs/nfsd/nfs4state.c @@ -7330,16 +7330,12 @@ nfsd4_release_lockowner(struct svc_rqst if (sop->so_is_open_owner || !same_owner_str(sop, owner)) continue; =20 - /* see if there are still any locks associated with it */ - lo =3D lockowner(sop); - list_for_each_entry(stp, &sop->so_stateids, st_perstateowner) { - if (check_for_locks(stp->st_stid.sc_file, lo)) { - status =3D nfserr_locks_held; - spin_unlock(&clp->cl_lock); - return status; - } + if (atomic_read(&sop->so_count) !=3D 1) { + spin_unlock(&clp->cl_lock); + return nfserr_locks_held; } =20 + lo =3D lockowner(sop); nfs4_get_stateowner(sop); break; } From nobody Tue Apr 28 06:30:16 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 6C88AC433EF for ; Fri, 3 Jun 2022 18:21:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347521AbiFCSUi (ORCPT ); Fri, 3 Jun 2022 14:20:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44878 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347240AbiFCSFp (ORCPT ); Fri, 3 Jun 2022 14:05:45 -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 4A1975B3D0; Fri, 3 Jun 2022 10:58:42 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id ADD60B82369; Fri, 3 Jun 2022 17:58:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0E01CC385A9; Fri, 3 Jun 2022 17:58:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279120; bh=Oa5o1RCQiC5uRTYQc+Azy0NH1P+Xp8hXfM1Ky8tfAaQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=HSjQrbmeeRglxaMsEPM2iC/k9gMOYpScm7woLAGPFS42JCaXN5i3UX5+KY4I3RMVY rCH8nrImIMRS3kR1S1gHSvecVWfI1qkEkOV7zuA5SYsLG8TMx8b5lpy3ijHzpscRPL KIKgiQ6p4sHAm7ycovq7z1bsgOgVQq55PAjw8ITA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Linus Torvalds , Song Liu , Daniel Borkmann Subject: [PATCH 5.18 59/67] bpf: Fill new bpf_prog_pack with illegal instructions Date: Fri, 3 Jun 2022 19:44:00 +0200 Message-Id: <20220603173822.420985539@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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: Song Liu commit d88bb5eed04ce50cc20e7f9282977841728be798 upstream. bpf_prog_pack enables sharing huge pages among multiple BPF programs. These pages are marked as executable before the JIT engine fill it with BPF programs. To make these pages safe, fill the hole bpf_prog_pack with illegal instructions before making it executable. Fixes: 57631054fae6 ("bpf: Introduce bpf_prog_pack allocator") Fixes: 33c9805860e5 ("bpf: Introduce bpf_jit_binary_pack_[alloc|finalize|fr= ee]") Reported-by: Linus Torvalds Signed-off-by: Song Liu Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20220520235758.1858153-2-song@kernel.org Signed-off-by: Greg Kroah-Hartman Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- kernel/bpf/core.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) --- a/kernel/bpf/core.c +++ b/kernel/bpf/core.c @@ -873,7 +873,7 @@ static size_t select_bpf_prog_pack_size( return size; } =20 -static struct bpf_prog_pack *alloc_new_pack(void) +static struct bpf_prog_pack *alloc_new_pack(bpf_jit_fill_hole_t bpf_fill_i= ll_insns) { struct bpf_prog_pack *pack; =20 @@ -886,6 +886,7 @@ static struct bpf_prog_pack *alloc_new_p kfree(pack); return NULL; } + bpf_fill_ill_insns(pack->ptr, bpf_prog_pack_size); bitmap_zero(pack->bitmap, bpf_prog_pack_size / BPF_PROG_CHUNK_SIZE); list_add_tail(&pack->list, &pack_list); =20 @@ -895,7 +896,7 @@ static struct bpf_prog_pack *alloc_new_p return pack; } =20 -static void *bpf_prog_pack_alloc(u32 size) +static void *bpf_prog_pack_alloc(u32 size, bpf_jit_fill_hole_t bpf_fill_il= l_insns) { unsigned int nbits =3D BPF_PROG_SIZE_TO_NBITS(size); struct bpf_prog_pack *pack; @@ -910,6 +911,7 @@ static void *bpf_prog_pack_alloc(u32 siz size =3D round_up(size, PAGE_SIZE); ptr =3D module_alloc(size); if (ptr) { + bpf_fill_ill_insns(ptr, size); set_vm_flush_reset_perms(ptr); set_memory_ro((unsigned long)ptr, size / PAGE_SIZE); set_memory_x((unsigned long)ptr, size / PAGE_SIZE); @@ -923,7 +925,7 @@ static void *bpf_prog_pack_alloc(u32 siz goto found_free_area; } =20 - pack =3D alloc_new_pack(); + pack =3D alloc_new_pack(bpf_fill_ill_insns); if (!pack) goto out; =20 @@ -1102,7 +1104,7 @@ bpf_jit_binary_pack_alloc(unsigned int p =20 if (bpf_jit_charge_modmem(size)) return NULL; - ro_header =3D bpf_prog_pack_alloc(size); + ro_header =3D bpf_prog_pack_alloc(size, bpf_fill_ill_insns); if (!ro_header) { bpf_jit_uncharge_modmem(size); return NULL; From nobody Tue Apr 28 06:30:16 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 A87F7C43334 for ; Fri, 3 Jun 2022 18:21:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347793AbiFCSVK (ORCPT ); Fri, 3 Jun 2022 14:21:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50080 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348048AbiFCSQM (ORCPT ); Fri, 3 Jun 2022 14:16:12 -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 A635662CEB; Fri, 3 Jun 2022 11:03:47 -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 09E7DB82435; Fri, 3 Jun 2022 17:58:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 38258C385A9; Fri, 3 Jun 2022 17:58:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279123; bh=sO/fkfrAJ5blRicrhVjpzLcwBfyTi7/AnGJfvCfo6Hs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=MRcBTePm7ERn55Dq8+oe8MSZeUlwSjKF40P06u3f7NxCX23VuC5E3NJ7D+XXa8RtD ie1bi1KI6GUmabxpqwpkIgb+FcLAHCwvBpbMHbCkmWqCTihkiM6G8wSgbxPmcaSXxB hW2FNEMjUlwU8vQWwo6jXYfcmdT5fFPsEzS+fSdo= 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.18 60/67] bpf: Fix potential array overflow in bpf_trampoline_get_progs() Date: Fri, 3 Jun 2022 19:44:01 +0200 Message-Id: <20220603173822.448594205@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- kernel/bpf/trampoline.c | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) --- a/kernel/bpf/trampoline.c +++ b/kernel/bpf/trampoline.c @@ -411,7 +411,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); @@ -422,7 +422,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) { @@ -500,16 +503,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 Tue Apr 28 06:30:16 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 01FBCCCA473 for ; Fri, 3 Jun 2022 18:21:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347219AbiFCSUI (ORCPT ); Fri, 3 Jun 2022 14:20:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40992 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347801AbiFCSGS (ORCPT ); Fri, 3 Jun 2022 14:06:18 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2BF3D5D5CD; Fri, 3 Jun 2022 10:59: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 68E21615E5; Fri, 3 Jun 2022 17:58:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 642E2C385A9; Fri, 3 Jun 2022 17:58:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279126; bh=4qTz1o5Y1+SqJrvnr8q5XVJw1rkEY0oLUtfdFOURr8A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=uAK016Byp+ScOQuO2eal9dYnqHNZ+DtYDKWSi7SINslFOxQfjf1BelEy4ZWVTkgvI B7XumuRK+EuGfEucL8IG9+I7mBECFskSM8YYkzqebzagv/djW2bWf9HT73dqbroZDb ffvwBRxbB+PUBqiCA1Sw0iRbm8VGi7u0Kt2aZOhY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Andrii Nakryiko , Alexei Starovoitov , Daniel Borkmann , Martin KaFai Lau Subject: [PATCH 5.18 61/67] bpf: Fix combination of jit blinding and pointers to bpf subprogs. Date: Fri, 3 Jun 2022 19:44:02 +0200 Message-Id: <20220603173822.476439161@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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: Alexei Starovoitov commit 4b6313cf99b0d51b49aeaea98ec76ca8161ecb80 upstream. The combination of jit blinding and pointers to bpf subprogs causes: [ 36.989548] BUG: unable to handle page fault for address: 00000001000000= 01 [ 36.990342] #PF: supervisor instruction fetch in kernel mode [ 36.990968] #PF: error_code(0x0010) - not-present page [ 36.994859] RIP: 0010:0x100000001 [ 36.995209] Code: Unable to access opcode bytes at RIP 0xffffffd7. [ 37.004091] Call Trace: [ 37.004351] [ 37.004576] ? bpf_loop+0x4d/0x70 [ 37.004932] ? bpf_prog_3899083f75e4c5de_F+0xe3/0x13b The jit blinding logic didn't recognize that ld_imm64 with an address of bpf subprogram is a special instruction and proceeded to randomize it. By itself it wouldn't have been an issue, but jit_subprogs() logic relies on two step process to JIT all subprogs and then JIT them again when addresses of all subprogs are known. Blinding process in the first JIT phase caused second JIT to miss adjustment of special ld_imm64. Fix this issue by ignoring special ld_imm64 instructions that don't have user controlled constants and shouldn't be blinded. Fixes: 69c087ba6225 ("bpf: Add bpf_for_each_map_elem() helper") Reported-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20220513011025.13344-1-alexei.starovoitov= @gmail.com Signed-off-by: Greg Kroah-Hartman Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- kernel/bpf/core.c | 10 ++++++++++ 1 file changed, 10 insertions(+) --- a/kernel/bpf/core.c +++ b/kernel/bpf/core.c @@ -1436,6 +1436,16 @@ struct bpf_prog *bpf_jit_blind_constants insn =3D clone->insnsi; =20 for (i =3D 0; i < insn_cnt; i++, insn++) { + if (bpf_pseudo_func(insn)) { + /* ld_imm64 with an address of bpf subprog is not + * a user controlled constant. Don't randomize it, + * since it will conflict with jit_subprogs() logic. + */ + insn++; + i++; + continue; + } + /* We temporarily need to hold the original ld64 insn * so that we can still access the first part in the * second blinding run. From nobody Tue Apr 28 06:30:16 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 B0384C433EF for ; Fri, 3 Jun 2022 18:21:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347152AbiFCST7 (ORCPT ); Fri, 3 Jun 2022 14:19:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44986 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348005AbiFCSGd (ORCPT ); Fri, 3 Jun 2022 14:06:33 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D1D6C5DBE6; Fri, 3 Jun 2022 10:59: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 71911B82430; Fri, 3 Jun 2022 17:58:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8E428C385A9; Fri, 3 Jun 2022 17:58:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279130; bh=kN0AN2TNyRTIymjPqzTViSmge+OvDBcFe42A1QKtWv8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=iJM3eu1659Fhu9NOSdnHhQHkL4U1KYiBR7ioyGnpMlLNHDYWa0kdF1pBL0ijFZcTF sp+D1t97gXOq0gElgpqz46D23Jw6mTZZhL60dpAnPj8xN5UE1yrNAqC0fsVmBTGlHC 5vnMFwsiS82iHz80jx9r5SSjIjM6rW+KZuZdoQBw= 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.18 62/67] bpf: Enlarge offset check value to INT_MAX in bpf_skb_{load,store}_bytes Date: Fri, 3 Jun 2022 19:44:03 +0200 Message-Id: <20220603173822.503895809@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- net/core/filter.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/net/core/filter.c +++ b/net/core/filter.c @@ -1687,7 +1687,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; @@ -1722,7 +1722,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 Tue Apr 28 06:30:16 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 74D25C43334 for ; Fri, 3 Jun 2022 18:18:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346960AbiFCSSk (ORCPT ); Fri, 3 Jun 2022 14:18:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44602 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347719AbiFCSGO (ORCPT ); Fri, 3 Jun 2022 14:06:14 -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 4246E5D194; Fri, 3 Jun 2022 10:59:22 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 4238B6167F; Fri, 3 Jun 2022 17:58:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D1F2CC3411C; Fri, 3 Jun 2022 17:58:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279133; bh=/UriPG/kavlvRQJG4JCjxU7QWJusRkAp5IS4zlxqq0M=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=1C0Mi5A4hF0a45lgp6wtuAeManWHMzS+80yUXtgdoe4JGxPP7d1P4ZEmG5EgVA5w7 Ag4NOU8C+0CdjrqPxXIbaMaKH42BybzU3OvsmgSMRrcl+JkHHGbNqNBMTHFCyqfd1X JGPKwUa84k3d46yVSeIUD1+/g3Qm/4tZvlMqvIGw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, KP Singh , Alexei Starovoitov , Martin KaFai Lau Subject: [PATCH 5.18 63/67] bpf: Fix usage of trace RCU in local storage. Date: Fri, 3 Jun 2022 19:44:04 +0200 Message-Id: <20220603173822.531727915@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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: KP Singh commit dcf456c9a095a6e71f53d6f6f004133ee851ee70 upstream. bpf_{sk,task,inode}_storage_free() do not need to use call_rcu_tasks_trace as no BPF program should be accessing the owner as it's being destroyed. The only other reader at this point is bpf_local_storage_map_free() which uses normal RCU. The only path that needs trace RCU are: * bpf_local_storage_{delete,update} helpers * map_{delete,update}_elem() syscalls Fixes: 0fe4b381a59e ("bpf: Allow bpf_local_storage to be used by sleepable = programs") Signed-off-by: KP Singh Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20220418155158.2865678-1-kpsingh@kernel.o= rg Signed-off-by: Greg Kroah-Hartman Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- include/linux/bpf_local_storage.h | 4 ++-- kernel/bpf/bpf_inode_storage.c | 4 ++-- kernel/bpf/bpf_local_storage.c | 29 +++++++++++++++++++---------- kernel/bpf/bpf_task_storage.c | 4 ++-- net/core/bpf_sk_storage.c | 6 +++--- 5 files changed, 28 insertions(+), 19 deletions(-) --- a/include/linux/bpf_local_storage.h +++ b/include/linux/bpf_local_storage.h @@ -143,9 +143,9 @@ void bpf_selem_link_storage_nolock(struc =20 bool bpf_selem_unlink_storage_nolock(struct bpf_local_storage *local_stora= ge, struct bpf_local_storage_elem *selem, - bool uncharge_omem); + bool uncharge_omem, bool use_trace_rcu); =20 -void bpf_selem_unlink(struct bpf_local_storage_elem *selem); +void bpf_selem_unlink(struct bpf_local_storage_elem *selem, bool use_trace= _rcu); =20 void bpf_selem_link_map(struct bpf_local_storage_map *smap, struct bpf_local_storage_elem *selem); --- a/kernel/bpf/bpf_inode_storage.c +++ b/kernel/bpf/bpf_inode_storage.c @@ -90,7 +90,7 @@ void bpf_inode_storage_free(struct inode */ bpf_selem_unlink_map(selem); free_inode_storage =3D bpf_selem_unlink_storage_nolock( - local_storage, selem, false); + local_storage, selem, false, false); } raw_spin_unlock_bh(&local_storage->lock); rcu_read_unlock(); @@ -149,7 +149,7 @@ static int inode_storage_delete(struct i if (!sdata) return -ENOENT; =20 - bpf_selem_unlink(SELEM(sdata)); + bpf_selem_unlink(SELEM(sdata), true); =20 return 0; } --- a/kernel/bpf/bpf_local_storage.c +++ b/kernel/bpf/bpf_local_storage.c @@ -106,7 +106,7 @@ static void bpf_selem_free_rcu(struct rc */ bool bpf_selem_unlink_storage_nolock(struct bpf_local_storage *local_stora= ge, struct bpf_local_storage_elem *selem, - bool uncharge_mem) + bool uncharge_mem, bool use_trace_rcu) { struct bpf_local_storage_map *smap; bool free_local_storage; @@ -150,11 +150,16 @@ bool bpf_selem_unlink_storage_nolock(str SDATA(selem)) RCU_INIT_POINTER(local_storage->cache[smap->cache_idx], NULL); =20 - call_rcu_tasks_trace(&selem->rcu, bpf_selem_free_rcu); + if (use_trace_rcu) + call_rcu_tasks_trace(&selem->rcu, bpf_selem_free_rcu); + else + kfree_rcu(selem, rcu); + return free_local_storage; } =20 -static void __bpf_selem_unlink_storage(struct bpf_local_storage_elem *sele= m) +static void __bpf_selem_unlink_storage(struct bpf_local_storage_elem *sele= m, + bool use_trace_rcu) { struct bpf_local_storage *local_storage; bool free_local_storage =3D false; @@ -169,12 +174,16 @@ static void __bpf_selem_unlink_storage(s raw_spin_lock_irqsave(&local_storage->lock, flags); if (likely(selem_linked_to_storage(selem))) free_local_storage =3D bpf_selem_unlink_storage_nolock( - local_storage, selem, true); + local_storage, selem, true, use_trace_rcu); raw_spin_unlock_irqrestore(&local_storage->lock, flags); =20 - if (free_local_storage) - call_rcu_tasks_trace(&local_storage->rcu, + if (free_local_storage) { + if (use_trace_rcu) + call_rcu_tasks_trace(&local_storage->rcu, bpf_local_storage_free_rcu); + else + kfree_rcu(local_storage, rcu); + } } =20 void bpf_selem_link_storage_nolock(struct bpf_local_storage *local_storage, @@ -214,14 +223,14 @@ void bpf_selem_link_map(struct bpf_local raw_spin_unlock_irqrestore(&b->lock, flags); } =20 -void bpf_selem_unlink(struct bpf_local_storage_elem *selem) +void bpf_selem_unlink(struct bpf_local_storage_elem *selem, bool use_trace= _rcu) { /* Always unlink from map before unlinking from local_storage * because selem will be freed after successfully unlinked from * the local_storage. */ bpf_selem_unlink_map(selem); - __bpf_selem_unlink_storage(selem); + __bpf_selem_unlink_storage(selem, use_trace_rcu); } =20 struct bpf_local_storage_data * @@ -466,7 +475,7 @@ bpf_local_storage_update(void *owner, st if (old_sdata) { bpf_selem_unlink_map(SELEM(old_sdata)); bpf_selem_unlink_storage_nolock(local_storage, SELEM(old_sdata), - false); + false, true); } =20 unlock: @@ -548,7 +557,7 @@ void bpf_local_storage_map_free(struct b migrate_disable(); __this_cpu_inc(*busy_counter); } - bpf_selem_unlink(selem); + bpf_selem_unlink(selem, false); if (busy_counter) { __this_cpu_dec(*busy_counter); migrate_enable(); --- a/kernel/bpf/bpf_task_storage.c +++ b/kernel/bpf/bpf_task_storage.c @@ -102,7 +102,7 @@ void bpf_task_storage_free(struct task_s */ bpf_selem_unlink_map(selem); free_task_storage =3D bpf_selem_unlink_storage_nolock( - local_storage, selem, false); + local_storage, selem, false, false); } raw_spin_unlock_irqrestore(&local_storage->lock, flags); bpf_task_storage_unlock(); @@ -192,7 +192,7 @@ static int task_storage_delete(struct ta if (!sdata) return -ENOENT; =20 - bpf_selem_unlink(SELEM(sdata)); + bpf_selem_unlink(SELEM(sdata), true); =20 return 0; } --- a/net/core/bpf_sk_storage.c +++ b/net/core/bpf_sk_storage.c @@ -40,7 +40,7 @@ static int bpf_sk_storage_del(struct soc if (!sdata) return -ENOENT; =20 - bpf_selem_unlink(SELEM(sdata)); + bpf_selem_unlink(SELEM(sdata), true); =20 return 0; } @@ -75,8 +75,8 @@ void bpf_sk_storage_free(struct sock *sk * sk_storage. */ bpf_selem_unlink_map(selem); - free_sk_storage =3D bpf_selem_unlink_storage_nolock(sk_storage, - selem, true); + free_sk_storage =3D bpf_selem_unlink_storage_nolock( + sk_storage, selem, true, false); } raw_spin_unlock_bh(&sk_storage->lock); rcu_read_unlock(); From nobody Tue Apr 28 06:30:16 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 B2DF5C43334 for ; Fri, 3 Jun 2022 18:19:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347022AbiFCSTz (ORCPT ); Fri, 3 Jun 2022 14:19:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45308 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348027AbiFCSGe (ORCPT ); Fri, 3 Jun 2022 14:06:34 -0400 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4E1C15DBF0; Fri, 3 Jun 2022 10:59:41 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id 68B31CE2491; Fri, 3 Jun 2022 17:58:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3E235C385A9; Fri, 3 Jun 2022 17:58:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279136; bh=OjwbpKNPDfe7GTw3ryhR0CVtFhv3cYyjK+edEN1nmDE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=J2YG4QfCZYhO072rxNEHT0l77w/IqsfcywRY/TqfTwBFWNAIzjnaX4b1aL/bakUX7 Gqwbd3WWlOqR7nDkAugqtAfXLW33Gs5s6LkvO0DS0DLoXBrxu83xsk1F6YKdCBk8g1 b0wbs7uiZxQTJAL6j5IYFc8g50YtLv9gGkqtRFz0= 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.18 64/67] bpf: Fix excessive memory allocation in stack_map_alloc() Date: Fri, 3 Jun 2022 19:44:05 +0200 Message-Id: <20220603173822.558677557@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- kernel/bpf/stackmap.c | 1 - 1 file changed, 1 deletion(-) --- a/kernel/bpf/stackmap.c +++ b/kernel/bpf/stackmap.c @@ -100,7 +100,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 Tue Apr 28 06:30:16 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 A799FC43334 for ; Fri, 3 Jun 2022 18:18:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242954AbiFCSSy (ORCPT ); Fri, 3 Jun 2022 14:18:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39992 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347900AbiFCSG1 (ORCPT ); Fri, 3 Jun 2022 14:06:27 -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 CED905D5F8; Fri, 3 Jun 2022 10:59:25 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id F3D09B82189; Fri, 3 Jun 2022 17:59:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4BAA8C385B8; Fri, 3 Jun 2022 17:58:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279139; bh=jylEjt/kulbTS7GurMgB9K2xH/8vWaxgWIIDnWNp0L8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GFqMcWw0VZtKRFds+RBdbUt+Ny7HnlVKzxlunQ1Hqx3ZJyeXfjvkiqzl1WYHYrXYA 2GPzqus93laXOFvQE094xrDxwd74Rks2JGPcgYIEXeNCsm/ECAkAbrXWTmsGIDtv3X XUDXGzwbRi/BHu8PMXHPO/6rpf9d2wSbLTFclxkI= 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.18 65/67] bpf: Reject writes for PTR_TO_MAP_KEY in check_helper_mem_access Date: Fri, 3 Jun 2022 19:44:06 +0200 Message-Id: <20220603173822.586723850@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- kernel/bpf/verifier.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -4861,6 +4861,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 Tue Apr 28 06:30:16 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 23391C43334 for ; Fri, 3 Jun 2022 18:19:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243620AbiFCSTN (ORCPT ); Fri, 3 Jun 2022 14:19:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45276 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348160AbiFCSGm (ORCPT ); Fri, 3 Jun 2022 14:06: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 B2FF8580ED; Fri, 3 Jun 2022 10:59: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 28831B82369; Fri, 3 Jun 2022 17:59:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6E9C2C385A9; Fri, 3 Jun 2022 17:59:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279145; bh=o55eYgmVhHvolPaEPQyRiu/SsiwcIdehGA0DAyJ0Ytw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=MSo/r6lklyO2rrJNMUSXsLSfJtd9u2hvqi2vKXurpnuWrC3l6Wggfr8e03BCaXOa2 8pBU9+9XCdhhGrOX//gS5dhJlP7syyI2owDvo3RpzODnjQiHO64h3Opxj2gdeSwzTp ExXEAf6Xo9qB1aEDcH2+rX4q6lecXajd+n0dkDtI= 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.18 66/67] bpf: Check PTR_TO_MEM | MEM_RDONLY in check_helper_mem_access Date: Fri, 3 Jun 2022 19:44:07 +0200 Message-Id: <20220603173822.614061520@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- kernel/bpf/verifier.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -4876,13 +4876,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 max_access =3D &env->prog->aux->max_rdonly_access; } else { From nobody Tue Apr 28 06:30:16 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 D650BC43334 for ; Fri, 3 Jun 2022 18:21:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347194AbiFCSUE (ORCPT ); Fri, 3 Jun 2022 14:20:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40990 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347834AbiFCSGT (ORCPT ); Fri, 3 Jun 2022 14:06:19 -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 281595D677; Fri, 3 Jun 2022 10:59:29 -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 19AEBB82438; Fri, 3 Jun 2022 17:59:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 86795C3411C; Fri, 3 Jun 2022 17:59:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279148; bh=nPcxQpf1ssmDisQFOLeXmXkRO9v1ounJGsftVl69TWI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=KZcKconOqpCxwv8w1gmarcjo4bt1MEmAaIT5AleTVroMLC78ByapCu1ItJwJVfKiX u1hLVQj01SE1RwoAyr/hMymUQeNwkB7vIeRtZOITp+FN+wOxDBoiMewJ9qRa11PcMT 5e/ulgasDr8BxIUu2iPehiBRUULAXSGnw2+bSuGg= 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.18 67/67] bpf: Do write access check for kfunc and global func Date: Fri, 3 Jun 2022 19:44:08 +0200 Message-Id: <20220603173822.641516438@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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 be77354a3d7ebd4897ee18eca26dca6df9224c76 upstream. When passing pointer to some map value to kfunc or global func, in verifier we are passing meta as NULL to various functions, which uses meta->raw_mode to check whether memory is being written to. Since some kfunc or global funcs may also write to memory pointers they receive as arguments, we must check for write access to memory. E.g. in some case map may be read only and this will be missed by current checks. However meta->raw_mode allows for uninitialized memory (e.g. on stack), since there is not enough info available through BTF, we must perform one call for read access (raw_mode =3D false), and one for write access (raw_mode =3D true). Fixes: e5069b9c23b3 ("bpf: Support pointers in global func args") Fixes: d583691c47dc ("bpf: Introduce mem, size argument pair support for kf= unc") Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20220319080827.73251-2-memxor@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Greg Kroah-Hartman Reported-by: Bagas Sanjaya Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Rudi Heitbaum --- kernel/bpf/verifier.c | 44 +++++++++++++++++++++++++++++--------------- 1 file changed, 29 insertions(+), 15 deletions(-) --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -4934,8 +4934,7 @@ static int check_mem_size_reg(struct bpf * out. Only upper bounds can be learned because retval is an * int type and negative retvals are allowed. */ - if (meta) - meta->msize_max_value =3D reg->umax_value; + meta->msize_max_value =3D reg->umax_value; =20 /* The register is SCALAR_VALUE; the access check * happens using its boundaries. @@ -4978,24 +4977,33 @@ static int check_mem_size_reg(struct bpf int check_mem_reg(struct bpf_verifier_env *env, struct bpf_reg_state *reg, u32 regno, u32 mem_size) { + bool may_be_null =3D type_may_be_null(reg->type); + struct bpf_reg_state saved_reg; + struct bpf_call_arg_meta meta; + int err; + if (register_is_null(reg)) return 0; =20 - if (type_may_be_null(reg->type)) { - /* Assuming that the register contains a value check if the memory - * access is safe. Temporarily save and restore the register's state as - * the conversion shouldn't be visible to a caller. - */ - const struct bpf_reg_state saved_reg =3D *reg; - int rv; - + memset(&meta, 0, sizeof(meta)); + /* Assuming that the register contains a value check if the memory + * access is safe. Temporarily save and restore the register's state as + * the conversion shouldn't be visible to a caller. + */ + if (may_be_null) { + saved_reg =3D *reg; mark_ptr_not_null_reg(reg); - rv =3D check_helper_mem_access(env, regno, mem_size, true, NULL); - *reg =3D saved_reg; - return rv; } =20 - return check_helper_mem_access(env, regno, mem_size, true, NULL); + err =3D check_helper_mem_access(env, regno, mem_size, true, &meta); + /* Check access for BPF_WRITE */ + meta.raw_mode =3D true; + err =3D err ?: check_helper_mem_access(env, regno, mem_size, true, &meta); + + if (may_be_null) + *reg =3D saved_reg; + + return err; } =20 int check_kfunc_mem_size_reg(struct bpf_verifier_env *env, struct bpf_reg_= state *reg, @@ -5004,16 +5012,22 @@ int check_kfunc_mem_size_reg(struct bpf_ struct bpf_reg_state *mem_reg =3D &cur_regs(env)[regno - 1]; bool may_be_null =3D type_may_be_null(mem_reg->type); struct bpf_reg_state saved_reg; + struct bpf_call_arg_meta meta; int err; =20 WARN_ON_ONCE(regno < BPF_REG_2 || regno > BPF_REG_5); =20 + memset(&meta, 0, sizeof(meta)); + if (may_be_null) { saved_reg =3D *mem_reg; mark_ptr_not_null_reg(mem_reg); } =20 - err =3D check_mem_size_reg(env, reg, regno, true, NULL); + err =3D check_mem_size_reg(env, reg, regno, true, &meta); + /* Check access for BPF_WRITE */ + meta.raw_mode =3D true; + err =3D err ?: check_mem_size_reg(env, reg, regno, true, &meta); =20 if (may_be_null) *mem_reg =3D saved_reg;