From: "David E. Box" <david.e.box@linux.intel.com>
To: "Hans de Goede" <hansg@kernel.org>,
"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
platform-driver-x86@vger.kernel.org
Cc: "David E. Box" <david.e.box@linux.intel.com>,
linux-kernel@vger.kernel.org
Subject: [PATCH 0/6] platform/x86/intel: Harden PMT discovery against malformed device data
Date: Fri, 30 Oct 2026 18:29:32 -0700 [thread overview]
Message-ID: <20261031012939.377995-1-david.e.box@linux.intel.com> (raw)
The Intel VSEC and PMT drivers build kernel copies and MMIO mappings from
discovery data read from the device:
1. DVSEC/VSEC config space,
2. the PMT discovery tables,
3. the feature tables pointed to from the discovery tables.
Several of these fields are used without being validated against the
buffers or BARs they describe, so a device reporting out-of-spec values can
make the drivers write past kernel structures, index past arrays, or map
MMIO outside of their own BARs.
These issues were found during an internal AI-assisted review of the PMT
codebase. An LLM was also used to draft the fixes and to build the test
tooling described below. Each finding was verified against the code, and
each patch was reviewed and tested before posting.
Patches 1-3 fix memory safety issues in the PMT discovery driver:
1. attr_size from the feature header sets the length of a
memcpy_fromio() into the fixed-size struct feature_table. The only
check was against the MMIO source size, which is also device
controlled, allowing an overflow of up to 1020 bytes. Bound it by
the destination, and skip the feature rather than failing probe.
2. Replace a WARN() on a bad table size with dev_err_probe(), since
malformed device data should not panic panic_on_warn systems.
3. The feature id is used as a BIT() shift and as an index into
pmt_feature_names[] before it is validated.
Patches 4-6 validate the MMIO ranges built from discovery data against
the BAR they claim to be in:
4. In the vsec driver, reject a DVSEC/VSEC table BAR index (tbir) that
is out of range or not a memory BAR, and discovery tables that
extend past the end of their BAR. The discovery BAR is recorded and
a helper is exported so the PMT drivers can apply the same check to
the ranges they build.
5. In the PMT discovery driver, check feature table resources against
the discovery BAR before mapping them.
6. In the PMT class driver, check telemetry and crashlog regions before
they are mapped, and mmappable by userspace, including ACCESS_BARID
regions whose BAR index can name the nonexistent BARs 6 and 7.
All patches carry Fixes tags. Patches 5 and 6 depend on the helper added
in patch 4.
Testing:
The malformed-data cases were tested on an emulated OOBMSM-style PMT device
in QEMU, extended with fault injection to corrupt one discovery field at a
time. With KASAN and UBSAN enabled, v7.3 showed each bug:
- an oops from the attr_size overflow corrupting struct feature (1),
- a WARN on a short table (2),
- a shift-out-of-bounds from the unvalidated feature id (3),
and discovery tables, feature tables and telemetry regions mapped
outside the BAR (4-6).
With the series, every case was rejected with its message and
no warnings, sanitizer reports or out-of-BAR mappings.
For regressions, PMT state with and without the series was compared on
- Diamond Rapids (OOBMSM with enhanaced discovery),
- Tiger Lake (which uses early client flag, shifted table offset)
- Nova Lake with a Battlemage card (VSEC data registered by xe).
The devices, telemetry and crashlog regions, and features were identical.
All regions read and mmapped in full and the discovery KUnit test passed.
The runtime testing above was done with the series on v7.3.
David E. Box (6):
platform/x86/intel/pmt/discovery: Bound attr_size against
feature_table capacity
platform/x86/intel/pmt/discovery: Avoid WARN for malformed tables
platform/x86/intel/pmt/discovery: Validate feature id before use
platform/x86/intel/vsec: Validate discovery table bounds against the
BAR
platform/x86/intel/pmt/discovery: Validate feature table against the
BAR
platform/x86/intel/pmt: Validate telemetry regions against the BAR
drivers/platform/x86/intel/pmt/class.c | 21 +++++
drivers/platform/x86/intel/pmt/discovery.c | 36 +++++++--
drivers/platform/x86/intel/vsec.c | 93 ++++++++++++++++++++--
include/linux/intel_vsec.h | 8 ++
4 files changed, 147 insertions(+), 11 deletions(-)
base-commit: c339f4010dea8b0d754f84ace70cd1b089878ef8
--
2.43.0
next reply other threads:[~2026-10-31 1:29 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-31 1:29 David E. Box [this message]
2026-10-31 1:29 ` [PATCH 1/6] platform/x86/intel/pmt/discovery: Bound attr_size against feature_table capacity David E. Box
2026-10-31 1:29 ` [PATCH 2/6] platform/x86/intel/pmt/discovery: Avoid WARN for malformed tables David E. Box
2026-10-31 1:29 ` [PATCH 3/6] platform/x86/intel/pmt/discovery: Validate feature id before use David E. Box
2026-10-31 1:29 ` [PATCH 4/6] platform/x86/intel/vsec: Validate discovery table bounds against the BAR David E. Box
2026-10-31 1:29 ` [PATCH 5/6] platform/x86/intel/pmt/discovery: Validate feature table " David E. Box
2026-10-31 1:29 ` [PATCH 6/6] platform/x86/intel/pmt: Validate telemetry regions " David E. Box
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=20261031012939.377995-1-david.e.box@linux.intel.com \
--to=david.e.box@linux.intel.com \
--cc=hansg@kernel.org \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=platform-driver-x86@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®