From nobody Fri Apr 10 11:12:39 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 D4B93C32773 for ; Fri, 19 Aug 2022 15:39:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349829AbiHSPjb (ORCPT ); Fri, 19 Aug 2022 11:39:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35816 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349732AbiHSPj3 (ORCPT ); Fri, 19 Aug 2022 11:39:29 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 54999D5981; Fri, 19 Aug 2022 08:39:28 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id E8378615E9; Fri, 19 Aug 2022 15:39:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F1786C433C1; Fri, 19 Aug 2022 15:39:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660923567; bh=08d/XJQRZjUU/QpAUPmqkFgDX+UBU86QCC66R/1vyNU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Fyl2Z2fdKCyKS4yvdYvGumRWeodBwlusZJgN9rd/K7YYrKd8TlMGJuxZBXPtmxXKa nPxntxTEynTJl0s3HR0olMGiauKNQD4D5BC3aDxFuEEgv0nf1BYGckJHCAE5Mk6PDp ykNAkpKwyXjTtG44TsVWapTuPM5xzF/Wvkw2a8Ss= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Max Schulze , Marco Elver Subject: [PATCH 5.19 1/7] Revert "mm: kfence: apply kmemleak_ignore_phys on early allocated pool" Date: Fri, 19 Aug 2022 17:39:17 +0200 Message-Id: <20220819153711.621086880@linuxfoundation.org> X-Mailer: git-send-email 2.37.2 In-Reply-To: <20220819153711.552247994@linuxfoundation.org> References: <20220819153711.552247994@linuxfoundation.org> User-Agent: quilt/0.67 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: Marco Elver This reverts commit 07313a2b29ed1079eaa7722624544b97b3ead84b. Commit 0c24e061196c21d5 ("mm: kmemleak: add rbtree and store physical address for objects allocated with PA") is not yet in 5.19 (but appears in 6.0). Without 0c24e061196c21d5, kmemleak still stores phys objects and non-phys objects in the same tree, and ignoring (instead of freeing) will cause insertions into the kmemleak object tree by the slab post-alloc hook to conflict with the pool object (see comment). Reports such as the following would appear on boot, and effectively disable kmemleak: | kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (= overlaps existing) | CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-v8-0815+ #5 | Hardware name: Raspberry Pi Compute Module 4 Rev 1.0 (DT) | Call trace: | dump_backtrace.part.0+0x1dc/0x1ec | show_stack+0x24/0x80 | dump_stack_lvl+0x8c/0xb8 | dump_stack+0x1c/0x38 | create_object.isra.0+0x490/0x4b0 | kmemleak_alloc+0x3c/0x50 | kmem_cache_alloc+0x2f8/0x450 | __proc_create+0x18c/0x400 | proc_create_reg+0x54/0xd0 | proc_create_seq_private+0x94/0x120 | init_mm_internals+0x1d8/0x248 | kernel_init_freeable+0x188/0x388 | kernel_init+0x30/0x150 | ret_from_fork+0x10/0x20 | kmemleak: Kernel memory leak detector disabled | kmemleak: Object 0xffffff806e24d000 (size 2097152): | kmemleak: comm "swapper", pid 0, jiffies 4294892296 | kmemleak: min_count =3D -1 | kmemleak: count =3D 0 | kmemleak: flags =3D 0x5 | kmemleak: checksum =3D 0 | kmemleak: backtrace: | kmemleak_alloc_phys+0x94/0xb0 | memblock_alloc_range_nid+0x1c0/0x20c | memblock_alloc_internal+0x88/0x100 | memblock_alloc_try_nid+0x148/0x1ac | kfence_alloc_pool+0x44/0x6c | mm_init+0x28/0x98 | start_kernel+0x178/0x3e8 | __primary_switched+0xc4/0xcc Reported-by: Max Schulze Signed-off-by: Marco Elver Link: https://lore.kernel.org/all/b33b33bc-2d06-1bcd-2df7-43678962b728@onli= ne.de/ Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Sudip Mukherjee Tested-by: Zan Aziz --- mm/kfence/core.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) --- a/mm/kfence/core.c +++ b/mm/kfence/core.c @@ -603,6 +603,14 @@ static unsigned long kfence_init_pool(vo addr +=3D 2 * PAGE_SIZE; } =20 + /* + * The pool is live and will never be deallocated from this point on. + * Remove the pool object from the kmemleak object tree, as it would + * otherwise overlap with allocations returned by kfence_alloc(), which + * are registered with kmemleak through the slab post-alloc hook. + */ + kmemleak_free(__kfence_pool); + return 0; } =20 @@ -615,16 +623,8 @@ static bool __init kfence_init_pool_earl =20 addr =3D kfence_init_pool(); =20 - if (!addr) { - /* - * The pool is live and will never be deallocated from this point on. - * Ignore the pool object from the kmemleak phys object tree, as it would - * otherwise overlap with allocations returned by kfence_alloc(), which - * are registered with kmemleak through the slab post-alloc hook. - */ - kmemleak_ignore_phys(__pa(__kfence_pool)); + if (!addr) return true; - } =20 /* * Only release unprotected pages, and do not try to go back and change From nobody Fri Apr 10 11:12:39 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 1906EC32771 for ; Fri, 19 Aug 2022 15:39:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348474AbiHSPjn (ORCPT ); Fri, 19 Aug 2022 11:39:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36024 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349732AbiHSPjh (ORCPT ); Fri, 19 Aug 2022 11:39:37 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6D64D1DA51; Fri, 19 Aug 2022 08:39:36 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 0923561614; Fri, 19 Aug 2022 15:39:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E9EFDC433D6; Fri, 19 Aug 2022 15:39:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660923575; bh=vzuhjQjb1bAt235wZBaUmvNgDR2rT4h0LO0AEMpSeF4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=HEvaV9InL/wxt4GWE7pPDDh11BlApeHWyLWuYkjbFEn92Wf7Mi8M5Dy4+hTB9Rwxi gUUPqVAi0EP0ayIolb5jrgdEDKBkmO6oddBDY1vtTbQMvJMuwsNh17XwdDulkRP5rp wo60CRESQfSYBBwh/ULIhdCj6nC8rzeujnEZwD48= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Nimish Mishra , Anirban Chakraborty , Debdeep Mukhopadhyay , Jerome Forissier , Jens Wiklander , Linus Torvalds Subject: [PATCH 5.19 2/7] tee: add overflow check in register_shm_helper() Date: Fri, 19 Aug 2022 17:39:18 +0200 Message-Id: <20220819153711.661594059@linuxfoundation.org> X-Mailer: git-send-email 2.37.2 In-Reply-To: <20220819153711.552247994@linuxfoundation.org> References: <20220819153711.552247994@linuxfoundation.org> User-Agent: quilt/0.67 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: Jens Wiklander commit 573ae4f13f630d6660008f1974c0a8a29c30e18a upstream. With special lengths supplied by user space, register_shm_helper() has an integer overflow when calculating the number of pages covered by a supplied user space memory region. This causes internal_get_user_pages_fast() a helper function of pin_user_pages_fast() to do a NULL pointer dereference: Unable to handle kernel NULL pointer dereference at virtual address 00000= 00000000010 Modules linked in: CPU: 1 PID: 173 Comm: optee_example_a Not tainted 5.19.0 #11 Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 pc : internal_get_user_pages_fast+0x474/0xa80 Call trace: internal_get_user_pages_fast+0x474/0xa80 pin_user_pages_fast+0x24/0x4c register_shm_helper+0x194/0x330 tee_shm_register_user_buf+0x78/0x120 tee_ioctl+0xd0/0x11a0 __arm64_sys_ioctl+0xa8/0xec invoke_syscall+0x48/0x114 Fix this by adding an an explicit call to access_ok() in tee_shm_register_user_buf() to catch an invalid user space address early. Fixes: 033ddf12bcf5 ("tee: add register user memory") Cc: stable@vger.kernel.org Reported-by: Nimish Mishra Reported-by: Anirban Chakraborty Reported-by: Debdeep Mukhopadhyay Suggested-by: Jerome Forissier Signed-off-by: Jens Wiklander Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Sudip Mukherjee Tested-by: Zan Aziz --- drivers/tee/tee_shm.c | 3 +++ 1 file changed, 3 insertions(+) --- a/drivers/tee/tee_shm.c +++ b/drivers/tee/tee_shm.c @@ -326,6 +326,9 @@ struct tee_shm *tee_shm_register_user_bu void *ret; int id; =20 + if (!access_ok((void __user *)addr, length)) + return ERR_PTR(-EFAULT); + mutex_lock(&teedev->mutex); id =3D idr_alloc(&teedev->idr, NULL, 1, 0, GFP_KERNEL); mutex_unlock(&teedev->mutex); From nobody Fri Apr 10 11:12:39 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 87086C32773 for ; Fri, 19 Aug 2022 15:39:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349859AbiHSPjx (ORCPT ); Fri, 19 Aug 2022 11:39:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36132 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349293AbiHSPjm (ORCPT ); Fri, 19 Aug 2022 11:39: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 1EF531D306; Fri, 19 Aug 2022 08:39: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 C95CFB8280C; Fri, 19 Aug 2022 15:39:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2C262C433D6; Fri, 19 Aug 2022 15:39:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660923578; bh=QXKbbD2rBMM2SVJ7jtAh4BSriiVTIwVcRFRHymGJ04g=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=b3SAMutcobvIlFHxK4hNs1QaoUFVLom0IE0Fxj9yVTU8M6obnF888bzlg4h0FDJf6 7/5i5WrdYUoVQaZhozyBAwQXzBk9z5xtlD7aUpXYe+8YPrDm41i4fN4duZ+0e4pWc7 uCSb/KkhALgtJHY5k9LWlb+HA7fMklgoWfmPWu/k= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jamal Hadi Salim , Stephen Hemminger , "David S. Miller" Subject: [PATCH 5.19 3/7] net_sched: cls_route: disallow handle of 0 Date: Fri, 19 Aug 2022 17:39:19 +0200 Message-Id: <20220819153711.691135829@linuxfoundation.org> X-Mailer: git-send-email 2.37.2 In-Reply-To: <20220819153711.552247994@linuxfoundation.org> References: <20220819153711.552247994@linuxfoundation.org> User-Agent: quilt/0.67 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: Jamal Hadi Salim commit 02799571714dc5dd6948824b9d080b44a295f695 upstream. Follows up on: https://lore.kernel.org/all/20220809170518.164662-1-cascardo@canonical.com/ handle of 0 implies from/to of universe realm which is not very sensible. Lets see what this patch will do: $sudo tc qdisc add dev $DEV root handle 1:0 prio //lets manufacture a way to insert handle of 0 $sudo tc filter add dev $DEV parent 1:0 protocol ip prio 100 \ route to 0 from 0 classid 1:10 action ok //gets rejected... Error: handle of 0 is not valid. We have an error talking to the kernel, -1 //lets create a legit entry.. sudo tc filter add dev $DEV parent 1:0 protocol ip prio 100 route from 10 \ classid 1:10 action ok //what did the kernel insert? $sudo tc filter ls dev $DEV parent 1:0 filter protocol ip pref 100 route chain 0 filter protocol ip pref 100 route chain 0 fh 0x000a8000 flowid 1:10 from 10 action order 1: gact action pass random type none pass val 0 index 1 ref 1 bind 1 //Lets try to replace that legit entry with a handle of 0 $ sudo tc filter replace dev $DEV parent 1:0 protocol ip prio 100 \ handle 0x000a8000 route to 0 from 0 classid 1:10 action drop Error: Replacing with handle of 0 is invalid. We have an error talking to the kernel, -1 And last, lets run Cascardo's POC: $ ./poc 0 0 -22 -22 -22 Signed-off-by: Jamal Hadi Salim Acked-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Sudip Mukherjee Tested-by: Zan Aziz --- net/sched/cls_route.c | 10 ++++++++++ 1 file changed, 10 insertions(+) --- a/net/sched/cls_route.c +++ b/net/sched/cls_route.c @@ -424,6 +424,11 @@ static int route4_set_parms(struct net * return -EINVAL; } =20 + if (!nhandle) { + NL_SET_ERR_MSG(extack, "Replacing with handle of 0 is invalid"); + return -EINVAL; + } + h1 =3D to_hash(nhandle); b =3D rtnl_dereference(head->table[h1]); if (!b) { @@ -477,6 +482,11 @@ static int route4_change(struct net *net int err; bool new =3D true; =20 + if (!handle) { + NL_SET_ERR_MSG(extack, "Creating with handle of 0 is invalid"); + return -EINVAL; + } + if (opt =3D=3D NULL) return handle ? -EINVAL : 0; From nobody Fri Apr 10 11:12:39 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 12306C32772 for ; Fri, 19 Aug 2022 15:39:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349867AbiHSPj5 (ORCPT ); Fri, 19 Aug 2022 11:39:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36180 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349338AbiHSPjp (ORCPT ); Fri, 19 Aug 2022 11:39:45 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2E51965E5; Fri, 19 Aug 2022 08:39: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 ams.source.kernel.org (Postfix) with ESMTPS id D420CB8280C; Fri, 19 Aug 2022 15:39:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 31FB4C433D6; Fri, 19 Aug 2022 15:39:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660923581; bh=YJw9ujvj844MIy5wukf49WencRlfOJACXwYnspuFcBY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=uLBYjEFp/+AQHBbpET12hl4YuZqLH5i2psyGK5pMJfLsXVTPhJ7FgIQAQJwDvVXBP +T6tOm6aXNt3CBDDkCbFGM6HLwbWHQmId3YjvA8CSMUIZVS+K6A+Ayiz5SE4RvGvZE OUzIA3kUn//teBiihkmD8qi0chs//UTGJGkYg64w= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, David Sterba , Qu Wenruo Subject: [PATCH 5.19 4/7] btrfs: only write the sectors in the vertical stripe which has data stripes Date: Fri, 19 Aug 2022 17:39:20 +0200 Message-Id: <20220819153711.724552991@linuxfoundation.org> X-Mailer: git-send-email 2.37.2 In-Reply-To: <20220819153711.552247994@linuxfoundation.org> References: <20220819153711.552247994@linuxfoundation.org> User-Agent: quilt/0.67 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: Qu Wenruo commit bd8f7e627703ca5707833d623efcd43f104c7b3f upstream. If we have only 8K partial write at the beginning of a full RAID56 stripe, we will write the following contents: 0 8K 32K 64K Disk 1 (data): |XX| | | Disk 2 (data): | | | Disk 3 (parity): |XXXXXXXXXXXXXXX|XXXXXXXXXXXXXXX| |X| means the sector will be written back to disk. Note that, although we won't write any sectors from disk 2, but we will write the full 64KiB of parity to disk. This behavior is fine for now, but not for the future (especially for RAID56J, as we waste quite some space to journal the unused parity stripes). So here we will also utilize the btrfs_raid_bio::dbitmap, anytime we queue a higher level bio into an rbio, we will update rbio::dbitmap to indicate which vertical stripes we need to writeback. And at finish_rmw(), we also check dbitmap to see if we need to write any sector in the vertical stripe. So after the patch, above example will only lead to the following writeback pattern: 0 8K 32K 64K Disk 1 (data): |XX| | | Disk 2 (data): | | | Disk 3 (parity): |XX| | | Acked-by: David Sterba Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Sudip Mukherjee Tested-by: Zan Aziz --- fs/btrfs/raid56.c | 53 +++++++++++++++++++++++++++++++++++++++++++++++++= ---- 1 file changed, 49 insertions(+), 4 deletions(-) --- a/fs/btrfs/raid56.c +++ b/fs/btrfs/raid56.c @@ -403,6 +403,9 @@ static void merge_rbio(struct btrfs_raid { bio_list_merge(&dest->bio_list, &victim->bio_list); dest->bio_list_bytes +=3D victim->bio_list_bytes; + /* Also inherit the bitmaps from @victim. */ + bitmap_or(dest->dbitmap, victim->dbitmap, dest->dbitmap, + dest->stripe_nsectors); dest->generic_bio_cnt +=3D victim->generic_bio_cnt; bio_list_init(&victim->bio_list); } @@ -944,6 +947,12 @@ static void rbio_orig_end_io(struct btrf =20 if (rbio->generic_bio_cnt) btrfs_bio_counter_sub(rbio->bioc->fs_info, rbio->generic_bio_cnt); + /* + * Clear the data bitmap, as the rbio may be cached for later usage. + * do this before before unlock_stripe() so there will be no new bio + * for this bio. + */ + bitmap_clear(rbio->dbitmap, 0, rbio->stripe_nsectors); =20 /* * At this moment, rbio->bio_list is empty, however since rbio does not @@ -1294,6 +1303,9 @@ static noinline void finish_rmw(struct b else BUG(); =20 + /* We should have at least one data sector. */ + ASSERT(bitmap_weight(rbio->dbitmap, rbio->stripe_nsectors)); + /* at this point we either have a full stripe, * or we've read the full stripe from the drive. * recalculate the parity and write the new results. @@ -1368,6 +1380,10 @@ static noinline void finish_rmw(struct b for (sectornr =3D 0; sectornr < rbio->stripe_nsectors; sectornr++) { struct sector_ptr *sector; =20 + /* This vertical stripe has no data, skip it. */ + if (!test_bit(sectornr, rbio->dbitmap)) + continue; + if (stripe < rbio->nr_data) { sector =3D sector_in_rbio(rbio, stripe, sectornr, 1); if (!sector) @@ -1394,6 +1410,10 @@ static noinline void finish_rmw(struct b for (sectornr =3D 0; sectornr < rbio->stripe_nsectors; sectornr++) { struct sector_ptr *sector; =20 + /* This vertical stripe has no data, skip it. */ + if (!test_bit(sectornr, rbio->dbitmap)) + continue; + if (stripe < rbio->nr_data) { sector =3D sector_in_rbio(rbio, stripe, sectornr, 1); if (!sector) @@ -1845,6 +1865,33 @@ static void btrfs_raid_unplug(struct blk run_plug(plug); } =20 +/* Add the original bio into rbio->bio_list, and update rbio::dbitmap. */ +static void rbio_add_bio(struct btrfs_raid_bio *rbio, struct bio *orig_bio) +{ + const struct btrfs_fs_info *fs_info =3D rbio->bioc->fs_info; + const u64 orig_logical =3D orig_bio->bi_iter.bi_sector << SECTOR_SHIFT; + const u64 full_stripe_start =3D rbio->bioc->raid_map[0]; + const u32 orig_len =3D orig_bio->bi_iter.bi_size; + const u32 sectorsize =3D fs_info->sectorsize; + u64 cur_logical; + + ASSERT(orig_logical >=3D full_stripe_start && + orig_logical + orig_len <=3D full_stripe_start + + rbio->nr_data * rbio->stripe_len); + + bio_list_add(&rbio->bio_list, orig_bio); + rbio->bio_list_bytes +=3D orig_bio->bi_iter.bi_size; + + /* Update the dbitmap. */ + for (cur_logical =3D orig_logical; cur_logical < orig_logical + orig_len; + cur_logical +=3D sectorsize) { + int bit =3D ((u32)(cur_logical - full_stripe_start) >> + fs_info->sectorsize_bits) % rbio->stripe_nsectors; + + set_bit(bit, rbio->dbitmap); + } +} + /* * our main entry point for writes from the rest of the FS. */ @@ -1861,9 +1908,8 @@ int raid56_parity_write(struct bio *bio, btrfs_put_bioc(bioc); return PTR_ERR(rbio); } - bio_list_add(&rbio->bio_list, bio); - rbio->bio_list_bytes =3D bio->bi_iter.bi_size; rbio->operation =3D BTRFS_RBIO_WRITE; + rbio_add_bio(rbio, bio); =20 btrfs_bio_counter_inc_noblocked(fs_info); rbio->generic_bio_cnt =3D 1; @@ -2268,8 +2314,7 @@ int raid56_parity_recover(struct bio *bi } =20 rbio->operation =3D BTRFS_RBIO_READ_REBUILD; - bio_list_add(&rbio->bio_list, bio); - rbio->bio_list_bytes =3D bio->bi_iter.bi_size; + rbio_add_bio(rbio, bio); =20 rbio->faila =3D find_logical_bio_stripe(rbio, bio); if (rbio->faila =3D=3D -1) { From nobody Fri Apr 10 11:12:39 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 429CCC32772 for ; Fri, 19 Aug 2022 15:40:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349879AbiHSPkA (ORCPT ); Fri, 19 Aug 2022 11:40:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36280 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349619AbiHSPjt (ORCPT ); Fri, 19 Aug 2022 11:39:49 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C1F6AE68D6; Fri, 19 Aug 2022 08:39: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 58665B8280D; Fri, 19 Aug 2022 15:39:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 43629C433C1; Fri, 19 Aug 2022 15:39:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660923585; bh=w8YA1h7bHAygZNSqHoIsEtpk+d6IKmNmlflXwWAXx10=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=AEXBthtcjW4dJYxli3KHsA8Q6BVwFkjOI2/7Z/7Ov2LLPUhCpYg+DLQdtaHi8ZQNg MnZrKoe9d4a6uKemP+HZY+QUYBJX5RbSWZ5KcU4dTF+ODr2KdOHoZq3im3fBYXBVrZ TmW1om/ou/FW+Ed+VmJ87aFk2B+HG4P9mqWMCBTU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, David Sterba , Qu Wenruo Subject: [PATCH 5.19 5/7] btrfs: raid56: dont trust any cached sector in __raid56_parity_recover() Date: Fri, 19 Aug 2022 17:39:21 +0200 Message-Id: <20220819153711.755011793@linuxfoundation.org> X-Mailer: git-send-email 2.37.2 In-Reply-To: <20220819153711.552247994@linuxfoundation.org> References: <20220819153711.552247994@linuxfoundation.org> User-Agent: quilt/0.67 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: Qu Wenruo commit f6065f8edeb25f4a9dfe0b446030ad995a84a088 upstream. [BUG] There is a small workload which will always fail with recent kernel: (A simplified version from btrfs/125 test case) mkfs.btrfs -f -m raid5 -d raid5 -b 1G $dev1 $dev2 $dev3 mount $dev1 $mnt xfs_io -f -c "pwrite -S 0xee 0 1M" $mnt/file1 sync umount $mnt btrfs dev scan -u $dev3 mount -o degraded $dev1 $mnt xfs_io -f -c "pwrite -S 0xff 0 128M" $mnt/file2 umount $mnt btrfs dev scan mount $dev1 $mnt btrfs balance start --full-balance $mnt umount $mnt The failure is always failed to read some tree blocks: BTRFS info (device dm-4): relocating block group 217710592 flags data|rai= d5 BTRFS error (device dm-4): parent transid verify failed on 38993920 wante= d 9 found 7 BTRFS error (device dm-4): parent transid verify failed on 38993920 wante= d 9 found 7 ... [CAUSE] With the recently added debug output, we can see all RAID56 operations related to full stripe 38928384: 56.1183: raid56_read_partial: full_stripe=3D38928384 devid=3D2 type=3DDAT= A1 offset=3D0 opf=3D0x0 physical=3D9502720 len=3D65536 56.1185: raid56_read_partial: full_stripe=3D38928384 devid=3D3 type=3DDAT= A2 offset=3D16384 opf=3D0x0 physical=3D9519104 len=3D16384 56.1185: raid56_read_partial: full_stripe=3D38928384 devid=3D3 type=3DDAT= A2 offset=3D49152 opf=3D0x0 physical=3D9551872 len=3D16384 56.1187: raid56_write_stripe: full_stripe=3D38928384 devid=3D3 type=3DDAT= A2 offset=3D0 opf=3D0x1 physical=3D9502720 len=3D16384 56.1188: raid56_write_stripe: full_stripe=3D38928384 devid=3D3 type=3DDAT= A2 offset=3D32768 opf=3D0x1 physical=3D9535488 len=3D16384 56.1188: raid56_write_stripe: full_stripe=3D38928384 devid=3D1 type=3DPQ1= offset=3D0 opf=3D0x1 physical=3D30474240 len=3D16384 56.1189: raid56_write_stripe: full_stripe=3D38928384 devid=3D1 type=3DPQ1= offset=3D32768 opf=3D0x1 physical=3D30507008 len=3D16384 56.1218: raid56_write_stripe: full_stripe=3D38928384 devid=3D3 type=3DDAT= A2 offset=3D49152 opf=3D0x1 physical=3D9551872 len=3D16384 56.1219: raid56_write_stripe: full_stripe=3D38928384 devid=3D1 type=3DPQ1= offset=3D49152 opf=3D0x1 physical=3D30523392 len=3D16384 56.2721: raid56_parity_recover: full stripe=3D38928384 eb=3D39010304 mirr= or=3D2 56.2723: raid56_parity_recover: full stripe=3D38928384 eb=3D39010304 mirr= or=3D2 56.2724: raid56_parity_recover: full stripe=3D38928384 eb=3D39010304 mirr= or=3D2 Before we enter raid56_parity_recover(), we have triggered some metadata write for the full stripe 38928384, this leads to us to read all the sectors from disk. Furthermore, btrfs raid56 write will cache its calculated P/Q sectors to avoid unnecessary read. This means, for that full stripe, after any partial write, we will have stale data, along with P/Q calculated using that stale data. Thankfully due to patch "btrfs: only write the sectors in the vertical stri= pe which has data stripes" we haven't submitted all the corrupted P/Q to disk. When we really need to recover certain range, aka in raid56_parity_recover(), we will use the cached rbio, along with its cached sectors (the full stripe is all cached). This explains why we have no event raid56_scrub_read_recover() triggered. Since we have the cached P/Q which is calculated using the stale data, the recovered one will just be stale. In our particular test case, it will always return the same incorrect metadata, thus causing the same error message "parent transid verify failed on 39010304 wanted 9 found 7" again and again. [BTRFS DESTRUCTIVE RMW PROBLEM] Test case btrfs/125 (and above workload) always has its trouble with the destructive read-modify-write (RMW) cycle: 0 32K 64K Data1: | Good | Good | Data2: | Bad | Bad | Parity: | Good | Good | In above case, if we trigger any write into Data1, we will use the bad data in Data2 to re-generate parity, killing the only chance to recovery Data2, thus Data2 is lost forever. This destructive RMW cycle is not specific to btrfs RAID56, but there are some btrfs specific behaviors making the case even worse: - Btrfs will cache sectors for unrelated vertical stripes. In above example, if we're only writing into 0~32K range, btrfs will still read data range (32K ~ 64K) of Data1, and (64K~128K) of Data2. This behavior is to cache sectors for later update. Incidentally commit d4e28d9b5f04 ("btrfs: raid56: make steal_rbio() subpage compatible") has a bug which makes RAID56 to never trust the cached sectors, thus slightly improve the situation for recovery. Unfortunately, follow up fix "btrfs: update stripe_sectors::uptodate in steal_rbio" will revert the behavior back to the old one. - Btrfs raid56 partial write will update all P/Q sectors and cache them This means, even if data at (64K ~ 96K) of Data2 is free space, and only (96K ~ 128K) of Data2 is really stale data. And we write into that (96K ~ 128K), we will update all the parity sectors for the full stripe. This unnecessary behavior will completely kill the chance of recovery. Thankfully, an unrelated optimization "btrfs: only write the sectors in the vertical stripe which has data stripes" will prevent submitting the write bio for untouched vertical sectors. That optimization will keep the on-disk P/Q untouched for a chance for later recovery. [FIX] Although we have no good way to completely fix the destructive RMW (unless we go full scrub for each partial write), we can still limit the damage. With patch "btrfs: only write the sectors in the vertical stripe which has data stripes" now we won't really submit the P/Q of unrelated vertical stripes, so the on-disk P/Q should still be fine. Now we really need to do is just drop all the cached sectors when doing recovery. By this, we have a chance to read the original P/Q from disk, and have a chance to recover the stale data, while still keep the cache to speed up regular write path. In fact, just dropping all the cache for recovery path is good enough to allow the test case btrfs/125 along with the small script to pass reliably. The lack of metadata write after the degraded mount, and forced metadata COW is saving us this time. So this patch will fix the behavior by not trust any cache in __raid56_parity_recover(), to solve the problem while still keep the cache useful. But please note that this test pass DOES NOT mean we have solved the destructive RMW problem, we just do better damage control a little better. Related patches: - btrfs: only write the sectors in the vertical stripe - d4e28d9b5f04 ("btrfs: raid56: make steal_rbio() subpage compatible") - btrfs: update stripe_sectors::uptodate in steal_rbio Acked-by: David Sterba Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Sudip Mukherjee Tested-by: Zan Aziz --- fs/btrfs/raid56.c | 15 ++++++--------- 1 file changed, 6 insertions(+), 9 deletions(-) --- a/fs/btrfs/raid56.c +++ b/fs/btrfs/raid56.c @@ -2218,9 +2218,12 @@ static int __raid56_parity_recover(struc atomic_set(&rbio->error, 0); =20 /* - * read everything that hasn't failed. Thanks to the - * stripe cache, it is possible that some or all of these - * pages are going to be uptodate. + * Read everything that hasn't failed. However this time we will + * not trust any cached sector. + * As we may read out some stale data but higher layer is not reading + * that stale part. + * + * So here we always re-read everything in recovery path. */ for (stripe =3D 0; stripe < rbio->real_stripes; stripe++) { if (rbio->faila =3D=3D stripe || rbio->failb =3D=3D stripe) { @@ -2231,13 +2234,7 @@ static int __raid56_parity_recover(struc for (sectornr =3D 0; sectornr < rbio->stripe_nsectors; sectornr++) { struct sector_ptr *sector; =20 - /* - * the rmw code may have already read this - * page in - */ sector =3D rbio_stripe_sector(rbio, stripe, sectornr); - if (sector->uptodate) - continue; =20 ret =3D rbio_add_io_sector(rbio, &bio_list, sector, stripe, sectornr, rbio->stripe_len, From nobody Fri Apr 10 11:12:39 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 5F632C32771 for ; Fri, 19 Aug 2022 15:40:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349754AbiHSPkJ (ORCPT ); Fri, 19 Aug 2022 11:40:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36324 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349506AbiHSPjv (ORCPT ); Fri, 19 Aug 2022 11:39:51 -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 C398565E5; Fri, 19 Aug 2022 08:39:50 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 7189FB8280F; Fri, 19 Aug 2022 15:39:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CD584C4314B; Fri, 19 Aug 2022 15:39:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660923588; bh=ADw06pRCuPZeTUd/Uq+mdKxMJyGKpyXRKWJnc9JYbVQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GObXdGItgM49Vv4iy/DHgcbZGw0WwMWQdLdayWxyiCuT+akEZOMkmlnab6U4FUD3X qakePs4Bcn4dsM3GualuVlIHuFHskTCXt1NxRIobF1kwJ2pIrdQd5s1ZqxQiy9wY7c CcM6nBx/bpFz0WiMRfqGhRbgippJfbOBWsalV79o= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, kexec@lists.infradead.org, keyrings@vger.kernel.org, linux-security-module@vger.kernel.org, Michal Suchanek , Coiby Xu , Mimi Zohar Subject: [PATCH 5.19 6/7] kexec, KEYS: make the code in bzImage64_verify_sig generic Date: Fri, 19 Aug 2022 17:39:22 +0200 Message-Id: <20220819153711.785888674@linuxfoundation.org> X-Mailer: git-send-email 2.37.2 In-Reply-To: <20220819153711.552247994@linuxfoundation.org> References: <20220819153711.552247994@linuxfoundation.org> User-Agent: quilt/0.67 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: Coiby Xu commit c903dae8941deb55043ee46ded29e84e97cd84bb upstream. commit 278311e417be ("kexec, KEYS: Make use of platform keyring for signature verify") adds platform keyring support on x86 kexec but not arm64. The code in bzImage64_verify_sig uses the keys on the .builtin_trusted_keys, .machine, if configured and enabled, .secondary_trusted_keys, also if configured, and .platform keyrings to verify the signed kernel image as PE file. Cc: kexec@lists.infradead.org Cc: keyrings@vger.kernel.org Cc: linux-security-module@vger.kernel.org Reviewed-by: Michal Suchanek Signed-off-by: Coiby Xu Signed-off-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Sudip Mukherjee Tested-by: Zan Aziz --- arch/x86/kernel/kexec-bzimage64.c | 20 +------------------- include/linux/kexec.h | 7 +++++++ kernel/kexec_file.c | 17 +++++++++++++++++ 3 files changed, 25 insertions(+), 19 deletions(-) --- a/arch/x86/kernel/kexec-bzimage64.c +++ b/arch/x86/kernel/kexec-bzimage64.c @@ -17,7 +17,6 @@ #include #include #include -#include =20 #include #include @@ -528,28 +527,11 @@ static int bzImage64_cleanup(void *loade return 0; } =20 -#ifdef CONFIG_KEXEC_BZIMAGE_VERIFY_SIG -static int bzImage64_verify_sig(const char *kernel, unsigned long kernel_l= en) -{ - int ret; - - ret =3D verify_pefile_signature(kernel, kernel_len, - VERIFY_USE_SECONDARY_KEYRING, - VERIFYING_KEXEC_PE_SIGNATURE); - if (ret =3D=3D -ENOKEY && IS_ENABLED(CONFIG_INTEGRITY_PLATFORM_KEYRING)) { - ret =3D verify_pefile_signature(kernel, kernel_len, - VERIFY_USE_PLATFORM_KEYRING, - VERIFYING_KEXEC_PE_SIGNATURE); - } - return ret; -} -#endif - const struct kexec_file_ops kexec_bzImage64_ops =3D { .probe =3D bzImage64_probe, .load =3D bzImage64_load, .cleanup =3D bzImage64_cleanup, #ifdef CONFIG_KEXEC_BZIMAGE_VERIFY_SIG - .verify_sig =3D bzImage64_verify_sig, + .verify_sig =3D kexec_kernel_verify_pe_sig, #endif }; --- a/include/linux/kexec.h +++ b/include/linux/kexec.h @@ -19,6 +19,7 @@ #include =20 #include +#include =20 /* Location of a reserved region to hold the crash kernel. */ @@ -212,6 +213,12 @@ static inline void *arch_kexec_kernel_im } #endif =20 +#ifdef CONFIG_KEXEC_SIG +#ifdef CONFIG_SIGNED_PE_FILE_VERIFICATION +int kexec_kernel_verify_pe_sig(const char *kernel, unsigned long kernel_le= n); +#endif +#endif + extern int kexec_add_buffer(struct kexec_buf *kbuf); int kexec_locate_mem_hole(struct kexec_buf *kbuf); =20 --- a/kernel/kexec_file.c +++ b/kernel/kexec_file.c @@ -123,6 +123,23 @@ void kimage_file_post_load_cleanup(struc } =20 #ifdef CONFIG_KEXEC_SIG +#ifdef CONFIG_SIGNED_PE_FILE_VERIFICATION +int kexec_kernel_verify_pe_sig(const char *kernel, unsigned long kernel_le= n) +{ + int ret; + + ret =3D verify_pefile_signature(kernel, kernel_len, + VERIFY_USE_SECONDARY_KEYRING, + VERIFYING_KEXEC_PE_SIGNATURE); + if (ret =3D=3D -ENOKEY && IS_ENABLED(CONFIG_INTEGRITY_PLATFORM_KEYRING)) { + ret =3D verify_pefile_signature(kernel, kernel_len, + VERIFY_USE_PLATFORM_KEYRING, + VERIFYING_KEXEC_PE_SIGNATURE); + } + return ret; +} +#endif + static int kexec_image_verify_sig(struct kimage *image, void *buf, unsigned long buf_len) { From nobody Fri Apr 10 11:12:39 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 DD609C32771 for ; Fri, 19 Aug 2022 15:40:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349890AbiHSPkL (ORCPT ); Fri, 19 Aug 2022 11:40:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36384 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349862AbiHSPjz (ORCPT ); Fri, 19 Aug 2022 11:39:55 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 097EFD5981; Fri, 19 Aug 2022 08:39: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 B3D33B8280F; Fri, 19 Aug 2022 15:39:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 05DD3C433C1; Fri, 19 Aug 2022 15:39:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660923591; bh=q01TiepYCgbd3YDF3Teq86Su7fa1NExU5eO/8Pw2Xpc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=X+dEgBBtmB7vhjo6RS6FqZ+Eojdbk9m/Dqt2/HbxYNf35l+rLuTmI2Lv0ksFWswxB O5Z2BxWA5E53k5cbW70k5OmQY+Y8exw4B43RdncEIqglaHsfMJSXNO7+vZh3nvIY1T GuufNQZ1CyfSQfyEA5eYZ8TQSonvhbYDrO8ndxvg= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Baoquan He , kexec@lists.infradead.org, keyrings@vger.kernel.org, linux-security-module@vger.kernel.org, Michal Suchanek , Will Deacon , Coiby Xu , Mimi Zohar Subject: [PATCH 5.19 7/7] arm64: kexec_file: use more system keyrings to verify kernel image signature Date: Fri, 19 Aug 2022 17:39:23 +0200 Message-Id: <20220819153711.815836041@linuxfoundation.org> X-Mailer: git-send-email 2.37.2 In-Reply-To: <20220819153711.552247994@linuxfoundation.org> References: <20220819153711.552247994@linuxfoundation.org> User-Agent: quilt/0.67 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: Coiby Xu commit 0d519cadf75184a24313568e7f489a7fc9b1be3b upstream. Currently, when loading a kernel image via the kexec_file_load() system call, arm64 can only use the .builtin_trusted_keys keyring to verify a signature whereas x86 can use three more keyrings i.e. .secondary_trusted_keys, .machine and .platform keyrings. For example, one resulting problem is kexec'ing a kernel image would be rejected with the error "Lockdown: kexec: kexec of unsigned images is restricted; see man kernel_lockdown.7". This patch set enables arm64 to make use of the same keyrings as x86 to verify the signature kexec'ed kernel image. Fixes: 732b7b93d849 ("arm64: kexec_file: add kernel signature verification = support") Cc: stable@vger.kernel.org # 105e10e2cf1c: kexec_file: drop weak attribute = from functions Cc: stable@vger.kernel.org # 34d5960af253: kexec: clean up arch_kexec_kerne= l_verify_sig Cc: stable@vger.kernel.org # 83b7bb2d49ae: kexec, KEYS: make the code in bz= Image64_verify_sig generic Acked-by: Baoquan He Cc: kexec@lists.infradead.org Cc: keyrings@vger.kernel.org Cc: linux-security-module@vger.kernel.org Co-developed-by: Michal Suchanek Signed-off-by: Michal Suchanek Acked-by: Will Deacon Signed-off-by: Coiby Xu Signed-off-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Sudip Mukherjee Tested-by: Zan Aziz --- arch/arm64/kernel/kexec_image.c | 11 +---------- 1 file changed, 1 insertion(+), 10 deletions(-) --- a/arch/arm64/kernel/kexec_image.c +++ b/arch/arm64/kernel/kexec_image.c @@ -14,7 +14,6 @@ #include #include #include -#include #include #include #include @@ -130,18 +129,10 @@ static void *image_load(struct kimage *i return NULL; } =20 -#ifdef CONFIG_KEXEC_IMAGE_VERIFY_SIG -static int image_verify_sig(const char *kernel, unsigned long kernel_len) -{ - return verify_pefile_signature(kernel, kernel_len, NULL, - VERIFYING_KEXEC_PE_SIGNATURE); -} -#endif - const struct kexec_file_ops kexec_image_ops =3D { .probe =3D image_probe, .load =3D image_load, #ifdef CONFIG_KEXEC_IMAGE_VERIFY_SIG - .verify_sig =3D image_verify_sig, + .verify_sig =3D kexec_kernel_verify_pe_sig, #endif };