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>,
Mario Limonciello <mario.limonciello@amd.com>,
<stable@vger.kernel.org>
Subject: [PATCH 2/3] platform/x86/amd: hfi: Fix out-of-bounds reads when parsing ranking data
Date: Mon, 21 Sep 2026 12:04:10 -0500 [thread overview]
Message-ID: <20260921170411.1149960-3-mario.limonciello@amd.com> (raw)
In-Reply-To: <20260921170411.1149960-1-mario.limonciello@amd.com>
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>
---
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];
}
--
2.55.0
next prev parent reply other threads:[~2026-09-21 17:04 UTC|newest]
Thread overview: 12+ 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 ` Mario Limonciello [this message]
2026-09-21 17:27 ` [PATCH 2/3] platform/x86/amd: hfi: Fix out-of-bounds reads when parsing ranking data Mario Limonciello
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
2026-10-12 15:54 ` Ilpo Järvinen
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=20260921170411.1149960-3-mario.limonciello@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®