From: Yicong Yang <yangyicong@huawei.com>
To: Jeremy Linton <jeremy.linton@arm.com>, <rafael@kernel.org>
Cc: <yangyicong@hisilicon.com>, <lenb@kernel.org>,
<jmeurin@google.com>, <linux-acpi@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <sudeep.holla@arm.com>,
Maximilian Heyne <mheyne@amazon.de>, <stable@vger.kernel.org>
Subject: Re: [PATCH] ACPI: PPTT: Fix processor subtable walk
Date: Thu, 8 May 2025 12:00:09 +0800 [thread overview]
Message-ID: <14393dc8-692d-eea2-c8c0-76125806622c@huawei.com> (raw)
In-Reply-To: <20250508023025.1301030-1-jeremy.linton@arm.com>
On 2025/5/8 10:30, Jeremy Linton wrote:
> The original PPTT code had a bug where the processor subtable length
> was not correctly validated when encountering a truncated
> acpi_pptt_processor node.
>
> Commit 7ab4f0e37a0f4 ("ACPI PPTT: Fix coding mistakes in a couple of
> sizeof() calls") attempted to fix this by validating the size is as
> large as the acpi_pptt_processor node structure. This introduced a
> regression where the last processor node in the PPTT table is ignored
> if it doesn't contain any private resources. That results errors like:
>
> ACPI PPTT: PPTT table found, but unable to locate core XX (XX)
> ACPI: SPE must be homogeneous
>
> Furthermore, it fail in a common case where the node length isn't
> equal to the acpi_pptt_processor structure size, leaving the original
> bug in a modified form.
>
> Correct the regression by adjusting the loop termination conditions as
> suggested by the bug reporters. An additional check performed after
> the subtable node type is detected, validates the acpi_pptt_processor
> node is fully contained in the PPTT table. Repeating the check in
> acpi_pptt_leaf_node() is largely redundant as the node is already
> known to be fully contained in the table.
>
> The case where a final truncated node's parent property is accepted,
> but the node itself is rejected should not be considered a bug.
>
> Fixes: 7ab4f0e37a0f4 ("ACPI PPTT: Fix coding mistakes in a couple of sizeof() calls")
> Reported-by: Maximilian Heyne <mheyne@amazon.de>
> Closes: https://lore.kernel.org/linux-acpi/20250506-draco-taped-15f475cd@mheyne-amazon/
> Reported-by: Yicong Yang <yangyicong@hisilicon.com>
Thanks for the fix. The last CPU in the PPTT can be parsed on my board with this.
Tested-by: Yicong Yang <yangyicong@hisilicon.com>
> Closes: https://lore.kernel.org/linux-acpi/20250507035124.28071-1-yangyicong@huawei.com/
> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
> Cc: Jean-Marc Eurin <jmeurin@google.com>
> Cc: <stable@vger.kernel.org>
> ---
> drivers/acpi/pptt.c | 11 ++++++++---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c
> index f73ce6e13065..54676e3d82dd 100644
> --- a/drivers/acpi/pptt.c
> +++ b/drivers/acpi/pptt.c
> @@ -231,16 +231,18 @@ static int acpi_pptt_leaf_node(struct acpi_table_header *table_hdr,
> sizeof(struct acpi_table_pptt));
> proc_sz = sizeof(struct acpi_pptt_processor);
>
> - while ((unsigned long)entry + proc_sz < table_end) {
> + /* ignore subtable types that are smaller than a processor node */
> + while ((unsigned long)entry + proc_sz <= table_end) {
> cpu_node = (struct acpi_pptt_processor *)entry;
> +
> if (entry->type == ACPI_PPTT_TYPE_PROCESSOR &&
> cpu_node->parent == node_entry)
> return 0;
> if (entry->length == 0)
> return 0;
> +
> entry = ACPI_ADD_PTR(struct acpi_subtable_header, entry,
> entry->length);
> -
> }
> return 1;
> }
> @@ -273,15 +275,18 @@ static struct acpi_pptt_processor *acpi_find_processor_node(struct acpi_table_he
> proc_sz = sizeof(struct acpi_pptt_processor);
>
> /* find the processor structure associated with this cpuid */
> - while ((unsigned long)entry + proc_sz < table_end) {
> + while ((unsigned long)entry + proc_sz <= table_end) {
> cpu_node = (struct acpi_pptt_processor *)entry;
>
> if (entry->length == 0) {
> pr_warn("Invalid zero length subtable\n");
> break;
> }
> + /* entry->length may not equal proc_sz, revalidate the processor structure length */
> if (entry->type == ACPI_PPTT_TYPE_PROCESSOR &&
> acpi_cpu_id == cpu_node->acpi_processor_id &&
> + (unsigned long)entry + entry->length <= table_end &&
> + entry->length == proc_sz + cpu_node->number_of_priv_resources * sizeof(u32) &&
> acpi_pptt_leaf_node(table_hdr, cpu_node)) {
> return (struct acpi_pptt_processor *)entry;
> }
>
next prev parent reply other threads:[~2025-05-08 4:16 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-08 2:30 [PATCH] ACPI: PPTT: Fix processor subtable walk Jeremy Linton
2025-05-08 4:00 ` Yicong Yang [this message]
2025-05-08 9:12 ` Sudeep Holla
2025-05-08 18:26 ` Rafael J. Wysocki
2025-05-08 14:50 ` Heyne, Maximilian
2025-05-14 13:07 ` Aishwarya
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=14393dc8-692d-eea2-c8c0-76125806622c@huawei.com \
--to=yangyicong@huawei.com \
--cc=jeremy.linton@arm.com \
--cc=jmeurin@google.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mheyne@amazon.de \
--cc=rafael@kernel.org \
--cc=stable@vger.kernel.org \
--cc=sudeep.holla@arm.com \
--cc=yangyicong@hisilicon.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.