From: Mario Limonciello <mario.limonciello@amd.com>
To: "Hans de Goede" <hansg@kernel.org>,
"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
Cc: "open list:AMD HETERO CORE HARDWARE FEEDBACK DRIVER"
<platform-driver-x86@vger.kernel.org>,
open list <linux-kernel@vger.kernel.org>,
stable@vger.kernel.org
Subject: Re: [PATCH 2/3] platform/x86/amd: hfi: Fix out-of-bounds reads when parsing ranking data
Date: Mon, 21 Sep 2026 12:27:13 -0500 [thread overview]
Message-ID: <8ce34344-4d09-4fe9-b356-101cb4d3679d@amd.com> (raw)
In-Reply-To: <20260921170411.1149960-3-mario.limonciello@amd.com>
On 9/21/26 12:04, Mario Limonciello wrote:
> amd_hfi_fill_metadata() parses CPU core ranking data out of the
> firmware-provided PCC shared memory but trusts two values it should not:
>
> - n_bitmaps is used to bound the outer loop that reads the APIC ID
> bitmaps from table_data[], but it is never validated against the size
> of the shared memory region (pcct_ext->length). A firmware-supplied
> count larger than the region reads past the end of table_data.
>
> - When resolving the base of the ranking data for a processor, the
> pointer is shifted by an extra "i * nr_class" term, where i is the
> current bitmap index. The per-processor offset is already applied
> through apic_index, which uses the running count of active processors
> (apic_start). The extra shift compounds for every logical processor
> beyond the first bitmap (APIC ID >= 32), reading out of bounds.
>
> Both result in out-of-bounds reads that can corrupt the ranking metrics,
> oops, or otherwise destabilise the system.
>
> Reject an n_bitmaps value that would not fit within the shared memory
> region, and drop the bogus "i * nr_class" term so the ranking data is
> addressed only through its correct per-processor offset.
>
> Cc: stable@vger.kernel.org
> Fixes: d4e95ea7a78e ("platform/x86: hfi: Parse CPU core ranking data from shared memory")
> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes:
https://sashiko.dev/#/bug/linux-bc92228c-d783-4b4b-af53-d40a346c4b05> ---
> drivers/platform/x86/amd/hfi/hfi.c | 20 ++++++++++++++++----
> 1 file changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/platform/x86/amd/hfi/hfi.c b/drivers/platform/x86/amd/hfi/hfi.c
> index e1c776b71f3e6..6d1d3b6c28a97 100644
> --- a/drivers/platform/x86/amd/hfi/hfi.c
> +++ b/drivers/platform/x86/amd/hfi/hfi.c
> @@ -20,6 +20,7 @@
> #include <linux/module.h>
> #include <linux/mailbox_client.h>
> #include <linux/mutex.h>
> +#include <linux/overflow.h>
> #include <linux/percpu-defs.h>
> #include <linux/platform_device.h>
> #include <linux/smp.h>
> @@ -168,6 +169,21 @@ static int amd_hfi_fill_metadata(struct amd_hfi_data *amd_hfi_data)
> return -EINVAL;
> }
>
> + /*
> + * The bitmaps enumerating the APIC IDs occupy the first n_bitmaps
> + * words of table_data. Reject a firmware-provided count that would
> + * push those reads past the end of the shared memory region.
> + */
> + if (struct_size(amd_hfi_data->shmem, table_data, amd_hfi_data->shmem->n_bitmaps) >
> + pcct_ext->length) {
> + dev_err(amd_hfi_data->dev, "invalid number of bitmaps: %u\n",
> + amd_hfi_data->shmem->n_bitmaps);
> + return -EINVAL;
> + }
> +
> + /* The ranking data for each processor follows the bitmaps */
> + u32 *table = amd_hfi_data->shmem->table_data + amd_hfi_data->shmem->n_bitmaps;
> +
> for (unsigned int i = 0; i < amd_hfi_data->shmem->n_bitmaps; i++) {
> u32 bitmap = amd_hfi_data->shmem->table_data[i];
>
> @@ -192,10 +208,6 @@ static int amd_hfi_fill_metadata(struct amd_hfi_data *amd_hfi_data)
> info = per_cpu_ptr(&amd_hfi_cpuinfo, cpu_index);
> apic_index = apic_start * info->nr_class * 2;
> for (unsigned int k = 0; k < info->nr_class; k++) {
> - u32 *table = amd_hfi_data->shmem->table_data +
> - amd_hfi_data->shmem->n_bitmaps +
> - i * info->nr_class;
> -
> info->amd_hfi_classes[k].eff = table[apic_index + 2 * k];
> info->amd_hfi_classes[k].perf = table[apic_index + 2 * k + 1];
> }
next prev parent reply other threads:[~2026-09-21 17:27 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-21 17:04 [PATCH 0/3] Fix a few Sashiko flagged issues on AMD_HFI Mario Limonciello
2026-09-21 17:04 ` [PATCH 1/3] platform/x86/amd: hfi: Fix a use-after-free when unloading the driver Mario Limonciello
2026-09-21 17:26 ` Mario Limonciello
2026-09-21 17:04 ` [PATCH 2/3] platform/x86/amd: hfi: Fix out-of-bounds reads when parsing ranking data Mario Limonciello
2026-09-21 17:27 ` Mario Limonciello [this message]
2026-09-21 17:04 ` [PATCH 3/3] platform/x86/amd: hfi: Rely on ACPI enumeration instead of a dummy device Mario Limonciello
2026-09-21 17:27 ` Mario Limonciello
2026-09-21 17:10 ` [PATCH 0/3] Fix a few Sashiko flagged issues on AMD_HFI Ilpo Järvinen
2026-09-21 17:13 ` Mario Limonciello
2026-09-21 17:22 ` Ilpo Järvinen
2026-09-21 17:26 ` Mario Limonciello
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=8ce34344-4d09-4fe9-b356-101cb4d3679d@amd.com \
--to=mario.limonciello@amd.com \
--cc=hansg@kernel.org \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=platform-driver-x86@vger.kernel.org \
--cc=stable@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®