From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BCBE3606A338 for ; Tue, 10 Nov 2026 20:07:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.a=rsa-sha256 header.s=bombadil.20210309 header.b=Q8UvAznu; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=h2PAuiZb DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To: Content-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Unsubscribe-Post:List-Owner; bh=fFSfGgw6bVYeUu0kiLvEaiITNG7sY4O64OeTREfeGfo=; b=Q8UvAznu7aXIFBpumplgyv+K8+ elUOPPdePOXcL/b7zHafZkk3qpPJG9g8vz9qy/dsSGr9hp6fCJFlo+Dozh96qpyYLgh+/SkD1aDFT VpqaIeQKQMQg88MEtt9VOt54tE2xS94DFFBU+mmw5LCil49H9ka5qIsFfwNskIHwORLmrmvhSh19L 10cIzYQpEeT5l++xg35vw4fO+tzi/byg/wf6O7v+Ggnr3pk7i1C51AwWWWB9Yv9scUm6MOV086blY ar65a0N7xKcgjiuSAOW4uTKY0JM8yCdU7JDIkjxcz+iu0vTmAlx6Z7mL5gFWVaJ7kKQ9lcA1p21cW SAJvfgwg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.100.1 #2 (Red Hat Linux)) id 1xQs87-00000004xKf-1o6c; Tue, 10 Nov 2026 20:07:43 +0000 Received: from tor.source.kernel.org ([172.105.4.254]) by bombadil.infradead.org with esmtps (Exim 4.100.1 #2 (Red Hat Linux)) id 1xQs86-00000004xKU-3My7 for kexec@lists.infradead.org; Tue, 10 Nov 2026 20:07:42 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 4284161CD3; Tue, 10 Nov 2026 20:07:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C2C381F008A5; Tue, 10 Nov 2026 20:07:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1794341262; bh=fFSfGgw6bVYeUu0kiLvEaiITNG7sY4O64OeTREfeGfo=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=h2PAuiZbL8+C9cFGu0hLkY/GW6LSnwFsQlh72teyZqoevLpXQn9BDXr5lwI6W2S9U oTPN/ufmKJHWcds6dUuuA0Jd+trPON6z/PfR9Y1KfVFLWbP3oX4WFz8J6qpkZe/06+ SRmC3dEP0M2Y63yi3A/6GIl5Q1TsPA5akE4xonvE7PWdTQ5QIefsR60dNZ2t8G/E4U +YjEWFgkB3D4cTaLXQAr5DIDR8EGa8+SvKr6hGQtH/iUmLAFkysVFTJ90fPne3SYrO F+gDw62x3g4d4og21o9Ff0IrTVbcKTKLUPM+6lJsW38SZtn/RcSSuxL2AZot1hVl4x jEt3A4OZQ/jHA== Date: Tue, 10 Nov 2026 22:07:35 +0200 From: Mike Rapoport To: =?iso-8859-1?B?Suly6W15?= Jean Cc: Andrew Morton , Baoquan He , Pasha Tatashin , Pratyush Yadav , Mimi Zohar , Roberto Sassu , Dmitry Kasatkin , Eric Snowberg , linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, kexec@lists.infradead.org, stable@vger.kernel.org Subject: Re: [PATCH] ima: fix kexec measurement buffer overflow after failed loads Message-ID: References: <20261108190404.1397829-2-Jeremy.Jean@oss.cyber.gouv.fr> X-Archived-By: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20261108190404.1397829-2-Jeremy.Jean@oss.cyber.gouv.fr> X-BeenThere: kexec@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "kexec" X-Spam-Status: No, score=-10.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on aws-us-west-2-korg-listserv-alma10-1 On Sun, Nov 08, 2026 at 07:04:04PM +0000, Jérémy Jean wrote: > When kexec_file_load() fails to install a new image, it can leave the > global IMA scratch buffer larger than the IMA segment of the current > image. When that image is executed, ima_update_kexec_buffer() copies > the larger log past the end of its reserved segment. In a test, KASAN > reports it as: ... > Limit the dump to the smaller value between the scratch size and the > installed image segment size. Update the IMA mapping only after > machine_kexec_post_load() succeeds. These are two different bugs and the changelog only explains the first. The second one is that if machine_kexec_post_load() fails (e.g. -ENOMEM in trans_pgd on arm64), ima_kexec_buffer is already switched to the segment of the image that is about to be freed, so the installed image loses the IMA update and kexec -e writes into freed pages. Please spell this out, or better split it into a separate patch. > diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c > --- a/kernel/kexec_file.c > +++ b/kernel/kexec_file.c > @@ -206,11 +206,13 @@ kimage_validate_signature(struct kimage *image) > > static int kexec_post_load(struct kimage *image, unsigned long flags) > { > + int ret = machine_kexec_post_load(image); > + > #ifdef CONFIG_IMA_KEXEC > - if (!(flags & KEXEC_FILE_ON_CRASH)) > + if (!ret && !(flags & KEXEC_FILE_ON_CRASH)) > ima_kexec_post_load(image); > #endif > - return machine_kexec_post_load(image); > + return ret; Nit: an early "if (ret) return ret;" reads better than folding the error into the IMA condition. > diff --git a/security/integrity/ima/ima_kexec.c b/security/integrity/ima/ima_kexec.c > --- a/security/integrity/ima/ima_kexec.c > +++ b/security/integrity/ima/ima_kexec.c > @@ -98,12 +97,14 @@ static int ima_dump_measurement_list(unsigned long *buffer_size, void **buffer, > + /* A failed replacement load may have resized the scratch buffer. */ > + ima_kexec_file.size = min_t(size_t, ima_kexec_file.size, segment_size); This prevents the overflow, but it treats the symptom at execute time. The actual problem is that ima_add_kexec_buffer() updates global state (ima_kexec_file and kexec_segment_size) for an image that may never be installed. When the failed load had a smaller measurement list (with staging the list can shrink), the dump is still truncated to the failed image's size and the next kernel gets an incomplete log. kexec_segment_size reported in the "kexec_execute" event is also the failed image's one. With the first hunk ima_kexec_post_load() runs only for an image that is going to be installed, so wouldn't it be cleaner to (re)size the scratch buffer and kexec_segment_size there, from image->ima_buffer_size? Then the comment you removed would actually become true. > @@ -239,7 +240,8 @@ static int ima_update_kexec_buffer(struct notifier_block *self, > - ret = ima_dump_measurement_list(&buf_size, &buf, kexec_segment_size); > + ret = ima_dump_measurement_list(&buf_size, &buf, > + kexec_image->ima_buffer_size); ima_kexec_buffer is not tied to kexec_image. After a successful kexec_file_load() followed by KEXEC_FILE_UNLOAD or by a successful kexec_load(), the old image is freed but ima_kexec_buffer still maps its pages. kexec_image->ima_buffer_size is 0 for a kexec_load() image, so with this patch the dump fails, but buf_size is still the header size and memcpy() writes it into freed pages. That's pre-existing and not a reason to hold this patch, but it's the same class of bug and I think IMA should check that ima_kexec_buffer belongs to kexec_image (or drop the mapping when the image is replaced) rather than rely on sizes matching. -- Sincerely yours, Mike.