From nobody Tue Dec 16 08:51:37 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 6329CC32771 for ; Mon, 26 Sep 2022 10:56:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236891AbiIZK4H (ORCPT ); Mon, 26 Sep 2022 06:56:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52068 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237137AbiIZKyi (ORCPT ); Mon, 26 Sep 2022 06:54:38 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A2C6F4DF32; Mon, 26 Sep 2022 03:28:55 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 39B5E601D2; Mon, 26 Sep 2022 10:28:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 300D3C433C1; Mon, 26 Sep 2022 10:28:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1664188134; bh=ZefyUdyjrZLLfgXROT+Cq73VQjC9GSiMHSF4lSNyBcw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=wH/EuCgSgUtcMYAHtm7QK3aHKvQG7ohnUJDAOhIGW3qtwV/cKnGngXcBTpk5oXC+x ys5fj99/UHwwVKh7SF4N82JMBlxGJzHv3sebNxj75eBlFmsICbV0kDarttgRkKTjMQ FkY59LchtZ0jRx1fU+7RvVZNElVq3c6/I9jUqcs4= 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.10 050/141] efi: x86: Wipe setup_data on pure EFI boot Date: Mon, 26 Sep 2022 12:11:16 +0200 Message-Id: <20220926100756.252548651@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220926100754.639112000@linuxfoundation.org> References: <20220926100754.639112000@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 */