From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0F26C36D4E1; Thu, 27 Aug 2026 20:37:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787863057; cv=none; b=M69OfuwHxBDS9r8nM+YTOFEedHrfVFgHeilNr3SVdQRocT6yRp21Tzwr5u0A0sU9Nj1a5erlHydXFx244dEkjLqsRLLadjM5D7OWKxLxz4FN6iKoGGXL06ed/IQwdg7UL6gW9hNIXbV8fOhRyEBs624iZ0Sk52LKZTDg6Ydt/Qw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787863057; c=relaxed/simple; bh=Cj0F2eVkw07A3li5Jqw2GJO5drIsDTHNt0MUBBggB+w=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=cG/Gd23wClnOyrXW1ESsdf2WVtfss7ZOcY9PGTf/AOA5hkQmZc6QgKzDlSYt7dPDOxBkriESMo22DMn0UZNE0Nr1l+gPn9pdIMekdwZCJyWQF0LaTzU92OhrycS3ztY0BfIz2srpUBAQvTWhnxXLD28ilH9qW+FycJyq+zi1Iro= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4DC821F00A3A; Thu, 27 Aug 2026 20:37:30 +0000 (UTC) From: Dave Jiang To: linux-acpi@vger.kernel.org, linux-cxl@vger.kernel.org Cc: rafael@kernel.org, tony.luck@intel.com, bp@alien8.de, guohanjun@huawei.com, mchehab@kernel.org, xueshuai@linux.alibaba.com, terry.bowman@amd.com, benjamin.cheatham@amd.com, alison.schofield@intel.com, sashiko-bot@kernel.org Subject: [PATCH v5 01/13] efi/cper: Reject CPER records with an out-of-range error_data_length Date: Thu, 27 Aug 2026 13:37:14 -0700 Message-ID: <20260827203726.3027541-2-dave.jiang@intel.com> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260827203726.3027541-1-dave.jiang@intel.com> References: <20260827203726.3027541-1-dave.jiang@intel.com> Precedence: bulk X-Mailing-List: linux-cxl@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit cper_estatus_check() sizes each section with acpi_hest_get_record_size(), which adds the firmware-controlled u32 error_data_length to the header size as a signed int (see ). A value in the top sizeof(*gdata) bytes of the u32 range wraps the sum small rather than large, so it slips past the "record_size > data_len" check: against the 72-byte v300 header, 0xffffffb9 sizes the record at 1 and acpi_hest_get_next() walks it a byte at a time, off the end. 0xffffffb8 sizes it at 0 and loops forever. Use check_add_overflow() to reject a sum that will not fit the int those helpers return, since the walk advances by that value. That subsumes the "acpi_hest_get_size(gdata) > data_len" test above it, because record_size is never smaller than the header. The later "len < sizeof(*foo)" guards rely on this per-section upper bound; they are lower bounds only. Reported-by: sashiko-bot@kernel.org Closes: https://sashiko.dev/#/patchset/20260714231835.303081-1-dave.jiang@intel.com?part=1 Fixes: 45b14a4ffcc1 ("efi: cper: Fix possible out-of-bounds access") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Dave Jiang --- v5: - Use check_add_overflow() rather than a u64 sum plus an INT_MAX test, and drop the now-redundant acpi_hest_get_size() bound (Jonathan Cameron). --- drivers/firmware/efi/cper.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c index 06b4fdb59917..332c78f2d561 100644 --- a/drivers/firmware/efi/cper.c +++ b/drivers/firmware/efi/cper.c @@ -752,7 +752,7 @@ EXPORT_SYMBOL_GPL(cper_estatus_check_header); int cper_estatus_check(const struct acpi_hest_generic_status *estatus) { struct acpi_hest_generic_data *gdata; - unsigned int data_len, record_size; + unsigned int data_len; int rc; rc = cper_estatus_check_header(estatus); @@ -762,10 +762,18 @@ int cper_estatus_check(const struct acpi_hest_generic_status *estatus) data_len = estatus->data_length; apei_estatus_for_each_section(estatus, gdata) { - if (acpi_hest_get_size(gdata) > data_len) + int record_size; + + /* + * The helpers sum these as a signed int, so a + * huge error_data_length wraps small rather than large and the + * walk then advances by that wrapped value. Reject a size an + * int cannot carry. + */ + if (check_add_overflow(acpi_hest_get_size(gdata), + gdata->error_data_length, &record_size)) return -EINVAL; - record_size = acpi_hest_get_record_size(gdata); if (record_size > data_len) return -EINVAL; -- 2.54.0