From nobody Fri Dec 19 17:33:16 2025 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 2F28CC07E9D for ; Mon, 26 Sep 2022 11:16:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234367AbiIZLQE (ORCPT ); Mon, 26 Sep 2022 07:16:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38586 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237538AbiIZLPN (ORCPT ); Mon, 26 Sep 2022 07:15: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 75BB162AAB; Mon, 26 Sep 2022 03:36: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 BC80460CEF; Mon, 26 Sep 2022 10:35:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CAF6EC433D7; Mon, 26 Sep 2022 10:35:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1664188537; bh=ZefyUdyjrZLLfgXROT+Cq73VQjC9GSiMHSF4lSNyBcw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Xmen2ttELWJlMCvjVFioEVUqIJXTmShPbSZwDtu/2CzpSkmiS8MBDnsQLXFIk2+M0 oHzbldVpQkbfBbHMhaHGhe2kVX0ysOuvN4sQKZh68j3A7BnWtrrGP5YAsbJC4cdnqO zLkTCejH7nsgNJGbqjXOas1qF9oXlSAK+aPFBjuc= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Ard Biesheuvel , "Jason A. Donenfeld" Subject: [PATCH 5.15 040/148] efi: x86: Wipe setup_data on pure EFI boot Date: Mon, 26 Sep 2022 12:11:14 +0200 Message-Id: <20220926100757.527201838@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220926100756.074519146@linuxfoundation.org> References: <20220926100756.074519146@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: Ard Biesheuvel commit 63bf28ceb3ebbe76048c3fb2987996ca1ae64f83 upstream. When booting the x86 kernel via EFI using the LoadImage/StartImage boot services [as opposed to the deprecated EFI handover protocol], the setup header is taken from the image directly, and given that EFI's LoadImage has no Linux/x86 specific knowledge regarding struct bootparams or struct setup_header, any absolute addresses in the setup header must originate from the file and not from a prior loading stage. Since we cannot generally predict where LoadImage() decides to load an image (*), such absolute addresses must be treated as suspect: even if a prior boot stage intended to make them point somewhere inside the [signed] image, there is no way to validate that, and if they point at an arbitrary location in memory, the setup_data nodes will not be covered by any signatures or TPM measurements either, and could be made to contain an arbitrary sequence of SETUP_xxx nodes, which could interfere quite badly with the early x86 boot sequence. (*) Note that, while LoadImage() does take a buffer/size tuple in addition to a device path, which can be used to provide the image contents directly, it will re-allocate such images, as the memory footprint of an image is generally larger than the PE/COFF file representation. Cc: # v5.10+ Link: https://lore.kernel.org/all/20220904165321.1140894-1-Jason@zx2c4.com/ Signed-off-by: Ard Biesheuvel Acked-by: Jason A. Donenfeld Signed-off-by: Greg Kroah-Hartman --- drivers/firmware/efi/libstub/x86-stub.c | 7 +++++++ 1 file changed, 7 insertions(+) --- a/drivers/firmware/efi/libstub/x86-stub.c +++ b/drivers/firmware/efi/libstub/x86-stub.c @@ -414,6 +414,13 @@ efi_status_t __efiapi efi_pe_entry(efi_h hdr->ramdisk_image =3D 0; hdr->ramdisk_size =3D 0; =20 + /* + * Disregard any setup data that was provided by the bootloader: + * setup_data could be pointing anywhere, and we have no way of + * authenticating or validating the payload. + */ + hdr->setup_data =3D 0; + efi_stub_entry(handle, sys_table_arg, boot_params); /* not reached */