From nobody Sat Feb 7 23:23:35 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 175B123314B; Fri, 19 Dec 2025 10:41:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766140866; cv=none; b=fDQhOcUmC6Mbw+BA6KNxa+2yzcAwCRHaje8+X6E+hK4jSQ7+nC1nxpQqEoNcQz5Ci20RUg1RtHP6dGIsNeiMzliY2wta8kgelplZkmv8CbURJKpzsmCPU90Q/9r8bXMHfHwxhnUUncAIscOmqEjaAO8Xpa8y5eZUi4aTap91HRo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766140866; c=relaxed/simple; bh=v46pcnHDRBpxHY5Ds3ULk0J6LHLabnL9oEV2KY94S9A=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=g2+FPCF6OiRFpX06VNL2t3X++ZHaFKxdd3yU6D1DPbJ0rOx3/7VGf3b6D5LA5sapM+62ywmldVVuCqxFBChJ2TLTCk24iy39oIl5Iu7eWiCNS2pwWdsTc+xrBmXfDduoUr4NQ4uAXtLtqV5Wz24Yoz+w4nzJhe/NTuvcyN36jSQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Z1GSHabA; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Z1GSHabA" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A7332C4CEF1; Fri, 19 Dec 2025 10:41:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1766140865; bh=v46pcnHDRBpxHY5Ds3ULk0J6LHLabnL9oEV2KY94S9A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Z1GSHabAeoKmV7ma9FklYGIYhdkrxjd0d+q6wjREiDkHmuVFm2DmrslBjbTq1G2Hu rNFJ484wWOa/FXXRwwPDAhPQ0KtU+WZ0DvCU028IkQtvlHvz0SC7o6AvJgACiY/jPa kIlmlBgpZJMxNi/kBMK99Q8WJGLAm0lqL99r3SdjdNisFvjHwWuiAtMYh4hZwMO5br HemoyWGDPyztjtAOavl/+pLh2egC1PbU22tDEdz1j8fXgOBrfnTTjTVirm1l4HEU3N 7XxI2gbRujPZKoxNsBTWe7QvCa1h8NMD369QP6CDGFU2rYvJTrL8IpXlWJpKPy8V/M yD9+rjnECY3GQ== Received: from mchehab by mail.kernel.org with local (Exim 4.99) (envelope-from ) id 1vWXux-00000005ktq-3yNu; Fri, 19 Dec 2025 11:41:03 +0100 From: Mauro Carvalho Chehab To: "Rafael J. Wysocki" Cc: Mauro Carvalho Chehab , "Ankit Agrawal" , "Borislav Petkov" , "Breno Leitao" , "Hanjun Guo" , "Ingo Molnar" , "Jason Tian" , "Jonathan Cameron" , "Len Brown" , "Mauro Carvalho Chehab" , "Shuai Xue" , "Smita Koralahalli" , "Tony Luck" , linux-acpi@vger.kernel.org, linux-edac@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v3 1/2] apei/ghes: ARM processor Error: don't go past allocated memory Date: Fri, 19 Dec 2025 11:40:43 +0100 Message-ID: X-Mailer: git-send-email 2.52.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Sender: Mauro Carvalho Chehab Content-Type: text/plain; charset="utf-8" If the BIOS generates a very small ARM Processor Error, or an incomplete one, the current logic will fail to deferrence err->section_length and ctx_info->size Add checks to avoid that. With such changes, such GHESv2 records won't cause OOPSes like this: [ 1.492129] Internal error: Oops: 0000000096000005 [#1] SMP [ 1.495449] Modules linked in: [ 1.495820] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:0 Not tainted 6.18.0-rc= 1-00017-gabadcc3553dd-dirty #18 PREEMPT [ 1.496125] Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 02/02= /2022 [ 1.496433] Workqueue: kacpi_notify acpi_os_execute_deferred [ 1.496967] pstate: 814000c5 (Nzcv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE= =3D--) [ 1.497199] pc : log_arm_hw_error+0x5c/0x200 [ 1.497380] lr : ghes_handle_arm_hw_error+0x94/0x220 0xffff8000811c5324 is in log_arm_hw_error (../drivers/ras/ras.c:75). 70 err_info =3D (struct cper_arm_err_info *)(err + 1); 71 ctx_info =3D (struct cper_arm_ctx_info *)(err_info + err->err_info_num); 72 ctx_err =3D (u8 *)ctx_info; 73 74 for (n =3D 0; n < err->context_info_num; n++) { 75 sz =3D sizeof(struct cper_arm_ctx_info) + ctx_info->size; 76 ctx_info =3D (struct cper_arm_ctx_info *)((long)ctx_info + sz); 77 ctx_len +=3D sz; 78 } 79 and similar ones while trying to access section_length on an error dump with too small size. Signed-off-by: Mauro Carvalho Chehab --- drivers/acpi/apei/ghes.c | 33 +++++++++++++++++++++++++++++---- drivers/ras/ras.c | 6 +++++- 2 files changed, 34 insertions(+), 5 deletions(-) diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c index 0dc767392a6c..9bf4ec84f160 100644 --- a/drivers/acpi/apei/ghes.c +++ b/drivers/acpi/apei/ghes.c @@ -552,21 +552,46 @@ static bool ghes_handle_arm_hw_error(struct acpi_hest= _generic_data *gdata, { struct cper_sec_proc_arm *err =3D acpi_hest_get_payload(gdata); int flags =3D sync ? MF_ACTION_REQUIRED : 0; + int length =3D gdata->error_data_length; char error_type[120]; bool queued =3D false; int sec_sev, i; char *p; =20 sec_sev =3D ghes_severity(gdata->error_severity); - log_arm_hw_error(err, sec_sev); + if (length >=3D sizeof(*err)) { + log_arm_hw_error(err, sec_sev); + } else { + pr_warn(FW_BUG "arm error length: %d\n", length); + pr_warn(FW_BUG "length is too small\n"); + pr_warn(FW_BUG "firmware-generated error record is incorrect\n"); + return false; + } + if (sev !=3D GHES_SEV_RECOVERABLE || sec_sev !=3D GHES_SEV_RECOVERABLE) return false; =20 p =3D (char *)(err + 1); + length -=3D sizeof(err); + for (i =3D 0; i < err->err_info_num; i++) { - struct cper_arm_err_info *err_info =3D (struct cper_arm_err_info *)p; - bool is_cache =3D err_info->type & CPER_ARM_CACHE_ERROR; - bool has_pa =3D (err_info->validation_bits & CPER_ARM_INFO_VALID_PHYSICA= L_ADDR); + struct cper_arm_err_info *err_info; + bool is_cache, has_pa; + + /* Ensure we have enough data for the error info header */ + length -=3D sizeof(*err_info); + if (length < 0) + break; + + err_info =3D (struct cper_arm_err_info *)p; + + /* Validate the claimed length before using it */ + length -=3D err_info->length; + if (length < 0) + break; + + is_cache =3D err_info->type & CPER_ARM_CACHE_ERROR; + has_pa =3D (err_info->validation_bits & CPER_ARM_INFO_VALID_PHYSICAL_ADD= R); =20 /* * The field (err_info->error_info & BIT(26)) is fixed to set to diff --git a/drivers/ras/ras.c b/drivers/ras/ras.c index 2a5b5a9fdcb3..03df3db62334 100644 --- a/drivers/ras/ras.c +++ b/drivers/ras/ras.c @@ -72,7 +72,11 @@ void log_arm_hw_error(struct cper_sec_proc_arm *err, con= st u8 sev) ctx_err =3D (u8 *)ctx_info; =20 for (n =3D 0; n < err->context_info_num; n++) { - sz =3D sizeof(struct cper_arm_ctx_info) + ctx_info->size; + sz =3D sizeof(struct cper_arm_ctx_info); + + if (sz + (long)ctx_info - (long)err >=3D err->section_length) + sz +=3D ctx_info->size; + ctx_info =3D (struct cper_arm_ctx_info *)((long)ctx_info + sz); ctx_len +=3D sz; } --=20 2.52.0 From nobody Sat Feb 7 23:23:35 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 45FB82F6928; Fri, 19 Dec 2025 10:41:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766140866; cv=none; b=CxyOdZLxDyPaThwuRSN/QRxl2P1FPp3FunC8reN1Aa0RH1K9Sq/eK5IKlPgqy6PnQij1Cqoumgtp8HoqVbhetxqJfgL2S42GTAELGckbEkVRJ6RrwZUtDl00leWLHbcWMw+635RmPb2i3TecGpGV0F3xuC0NQoeqUZrWIMDQfxc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766140866; c=relaxed/simple; bh=pjJIBdeGr/2HUnvT1qt1BXIGueYL8pPwlvX7pDcJC/U=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=pKJsJ78K3TyVQs3iB/FhVldtjKr2xINdT5U2q+mRqKfIqdiB/MbG9hcfcRNNCf/ZlwiPPayDSpdf1q0kP0LRmQLqVrlDhSXUpQSqVo0XyU6oWLgN84o8uCS8TxWQX12/8XlfCMs5gOrLpNTrJBcz1LwecSkxpwUf+4shm84d7FQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=aRM2m+J7; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="aRM2m+J7" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D8278C116D0; Fri, 19 Dec 2025 10:41:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1766140865; bh=pjJIBdeGr/2HUnvT1qt1BXIGueYL8pPwlvX7pDcJC/U=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=aRM2m+J7tNKKhZU5aJNvPmNCyHID+lL07a06UMgrbLNP3BMBGSiby8ntNjUhNPv9V b30CI8suXkOQbrIFpJduqwF6ULwwJmyEnGQA1hU7NuDGJXkhD0F4bF7vvFcyQ2+0BZ LHo3JOPpSoJrDbR/a6ROMvImUkOrr/+aXFaxOofz1vHBBhaK8kSRb3U/UZBZwZdj9O VhN6OTLLoKITfV8kiCYCBhRahq9KfxkSK1OdbCdeM9X9maxBgLUj8DTJJ/u6yQQ911 ++tTcbHBzuGCQM9JzXtyfQMjfJF2FIdgLH/q6D3UEtKyHh+gI367VScwbalbO//z+k LnjgTTRtwDfYg== Received: from mchehab by mail.kernel.org with local (Exim 4.99) (envelope-from ) id 1vWXux-00000005ktu-45Mz; Fri, 19 Dec 2025 11:41:03 +0100 From: Mauro Carvalho Chehab To: "Rafael J. Wysocki" Cc: Mauro Carvalho Chehab , "Ard Biesheuvel" , "Borislav Petkov" , "Dave Jiang" , "Fan Ni" , "Jonathan Cameron" , "Shuai Xue" , "Smita Koralahalli" , linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v3 2/2] efi/cper: don't go past the ARM processor CPER record buffer Date: Fri, 19 Dec 2025 11:40:44 +0100 Message-ID: X-Mailer: git-send-email 2.52.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Sender: Mauro Carvalho Chehab Content-Type: text/plain; charset="utf-8" There's a logic inside ghes/cper to detect if the section_length is too small, but it doesn't detect if it is too big. Currently, if the firmware receives an ARM processor CPER record stating that a section length is big, kernel will blindly trust section_length, producing a very long dump. For instance, a 67 bytes record with ERR_INFO_NUM set 46198 and section length set to 854918320 would dump a lot of data going a way past the firmware memory-mapped area. Fix it by adding a logic to prevent it to go past the buffer if ERR_INFO_NUM is too big, making it report instead: [Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 1 [Hardware Error]: event severity: recoverable [Hardware Error]: Error 0, type: recoverable [Hardware Error]: section_type: ARM processor error [Hardware Error]: MIDR: 0xff304b2f8476870a [Hardware Error]: section length: 854918320, CPER size: 67 [Hardware Error]: section length is too big [Hardware Error]: firmware-generated error record is incorrect [Hardware Error]: ERR_INFO_NUM is 46198 Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Jonathan Cameron --- drivers/firmware/efi/cper-arm.c | 12 ++++++++---- drivers/firmware/efi/cper.c | 3 ++- include/linux/cper.h | 3 ++- 3 files changed, 12 insertions(+), 6 deletions(-) diff --git a/drivers/firmware/efi/cper-arm.c b/drivers/firmware/efi/cper-ar= m.c index 76542a53e202..b21cb1232d82 100644 --- a/drivers/firmware/efi/cper-arm.c +++ b/drivers/firmware/efi/cper-arm.c @@ -226,7 +226,8 @@ static void cper_print_arm_err_info(const char *pfx, u3= 2 type, } =20 void cper_print_proc_arm(const char *pfx, - const struct cper_sec_proc_arm *proc) + const struct cper_sec_proc_arm *proc, + u32 length) { int i, len, max_ctx_type; struct cper_arm_err_info *err_info; @@ -238,9 +239,12 @@ void cper_print_proc_arm(const char *pfx, =20 len =3D proc->section_length - (sizeof(*proc) + proc->err_info_num * (sizeof(*err_info))); - if (len < 0) { - printk("%ssection length: %d\n", pfx, proc->section_length); - printk("%ssection length is too small\n", pfx); + + if (len < 0 || proc->section_length > length) { + printk("%ssection length: %d, CPER size: %d\n", + pfx, proc->section_length, length); + printk("%ssection length is too %s\n", pfx, + (len < 0) ? "small" : "big"); printk("%sfirmware-generated error record is incorrect\n", pfx); printk("%sERR_INFO_NUM is %d\n", pfx, proc->err_info_num); return; diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c index 0232bd040f61..88fc0293f876 100644 --- a/drivers/firmware/efi/cper.c +++ b/drivers/firmware/efi/cper.c @@ -659,7 +659,8 @@ cper_estatus_print_section(const char *pfx, struct acpi= _hest_generic_data *gdata =20 printk("%ssection_type: ARM processor error\n", newpfx); if (gdata->error_data_length >=3D sizeof(*arm_err)) - cper_print_proc_arm(newpfx, arm_err); + cper_print_proc_arm(newpfx, arm_err, + gdata->error_data_length); else goto err_section_too_small; #endif diff --git a/include/linux/cper.h b/include/linux/cper.h index 5b1236d8c65b..440b35e459e5 100644 --- a/include/linux/cper.h +++ b/include/linux/cper.h @@ -595,7 +595,8 @@ void cper_mem_err_pack(const struct cper_sec_mem_err *, const char *cper_mem_err_unpack(struct trace_seq *, struct cper_mem_err_compact *); void cper_print_proc_arm(const char *pfx, - const struct cper_sec_proc_arm *proc); + const struct cper_sec_proc_arm *proc, + u32 length); void cper_print_proc_ia(const char *pfx, const struct cper_sec_proc_ia *proc); int cper_mem_err_location(struct cper_mem_err_compact *mem, char *msg); --=20 2.52.0