From: sashiko-bot@kernel.org
To: "Dapeng Mi" <dapeng1.mi@linux.intel.com>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [Patch v7 24/24] perf/x86/intel: Add sanity check for PEBS fragment size
Date: Sat, 25 Apr 2026 03:53:38 +0000 [thread overview]
Message-ID: <20260425035339.8032DC2BCB2@smtp.kernel.org> (raw)
In-Reply-To: <20260324004118.3772171-25-dapeng1.mi@linux.intel.com>
Sashiko AI review found 3 potential issue(s):
- [Critical] Skipping setup_sample() for corrupted records does not discard the record, but instead leaks stale register states to userspace.
- [High] The global `corrupted` flag falsely invalidates valid pending samples for unrelated PMU counters.
- [Medium] The corruption checks fail to flag records with out-of-bounds final fragments or zero-sized fragments as corrupted.
--
commit ed1fa3eb36814252a303cf5b2e6f3f4bfd3ed81e
Author: Dapeng Mi <dapeng1.mi@linux.intel.com>
perf/x86/intel: Add sanity check for PEBS fragment size
This commit adds a sanity check to prevent potential infinite loops
caused by corrupted PEBS fragment sizes. It intends to discard
corrupted PEBS records and all subsequent records.
> diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c
> index 19f96d9ae04b5..e7bc6a37a3575 100644
> --- a/arch/x86/events/intel/ds.c
> +++ b/arch/x86/events/intel/ds.c
> @@ -2951,13 +2951,17 @@ __intel_pmu_pebs_last_event(struct perf_event *event,
> struct pt_regs *iregs,
> struct pt_regs *regs,
> struct perf_sample_data *data,
> - void *at,
> - int count,
> + void *at, int count, bool corrupted,
> setup_fn setup_sample)
> {
> struct hw_perf_event *hwc = &event->hw;
>
> - setup_sample(event, iregs, at, data, regs);
> + /* Skip parsing corrupted PEBS record. */
> + if (corrupted)
> + perf_sample_data_init(data, 0, event->hw.last_period);
> + else
> + setup_sample(event, iregs, at, data, regs);
> +
The commit message states that corrupted PEBS records will be discarded, but
skipping setup_sample() still allows the execution to continue to
perf_event_output() or perf_event_overflow() located further down in this
function.
Since regs points to a per-CPU x86_pebs_regs, and it is not updated with
the current hardware context when setup_sample() is skipped, does this emit
stale register states from previously processed PEBS records into the
userspace ring buffer?
[ ... ]
> @@ -3391,6 +3399,10 @@ static int intel_pmu_drain_arch_pebs(struct pt_regs *iregs,
> if (!header->size)
> break;
If a fragment has header->size == 0, the loop breaks and reaches done: with
corrupted == false.
Does this miss flagging malformed zero-sized fragments as corrupted, allowing
them to be parsed and potentially causing out-of-bounds reads?
> at += header->size;
> + if (WARN_ON_ONCE(at >= top)) {
> + corrupted = true;
> + goto done;
> + }
> header = at;
> }
>
> /* Skip last fragment or the single record */
> at += header->size;
> }
If the final fragment of a record (where arch_pebs_record_continued()
is false) has an out-of-bounds size, at += header->size; is executed
and the loop terminates naturally with corrupted == false.
Could this allow out-of-bounds reads past ds->pebs_index when the unflagged
malformed record is parsed by setup_arch_pebs_sample_data()?
> +done:
> __intel_pmu_handle_last_pebs_record(iregs, regs, data, mask,
> - counts, last,
> + counts, last, corrupted,
> setup_arch_pebs_sample_data);
Here a single corrupted flag is passed for the entire PEBS buffer drain
operation.
If one PMU counter encounters a corrupted record and jumps to done:, this
global flag is applied to the last events of all active counters.
Does this falsely invalidate perfectly valid pending samples for unrelated
PMU counters, and subject them to the stale register leak described above?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260324004118.3772171-1-dapeng1.mi@linux.intel.com?part=24
next prev parent reply other threads:[~2026-04-25 3:53 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-24 0:40 [Patch v7 00/24] Support SIMD/eGPRs/SSP registers sampling for perf Dapeng Mi
2026-03-24 0:40 ` [Patch v7 01/24] perf/x86: Move hybrid PMU initialization before x86_pmu_starting_cpu() Dapeng Mi
2026-03-24 0:40 ` [Patch v7 02/24] perf/x86/intel: Avoid PEBS event on fixed counters without extended PEBS Dapeng Mi
2026-03-24 0:40 ` [Patch v7 03/24] perf/x86/intel: Enable large PEBS sampling for XMMs Dapeng Mi
2026-03-24 0:40 ` [Patch v7 04/24] perf/x86/intel: Convert x86_perf_regs to per-cpu variables Dapeng Mi
2026-03-24 0:40 ` [Patch v7 05/24] perf: Eliminate duplicate arch-specific functions definations Dapeng Mi
2026-03-24 0:41 ` [Patch v7 06/24] perf/x86: Use x86_perf_regs in the x86 nmi handler Dapeng Mi
2026-03-24 0:41 ` [Patch v7 07/24] perf/x86: Introduce x86-specific x86_pmu_setup_regs_data() Dapeng Mi
2026-03-25 5:18 ` Mi, Dapeng
2026-03-24 0:41 ` [Patch v7 08/24] x86/fpu/xstate: Add xsaves_nmi() helper Dapeng Mi
2026-03-24 0:41 ` [Patch v7 09/24] x86/fpu: Ensure TIF_NEED_FPU_LOAD is set after saving FPU state Dapeng Mi
2026-03-24 0:41 ` [Patch v7 10/24] perf: Move and rename has_extended_regs() for ARCH-specific use Dapeng Mi
2026-03-24 0:41 ` [Patch v7 11/24] perf/x86: Enable XMM Register Sampling for Non-PEBS Events Dapeng Mi
2026-03-25 7:30 ` Mi, Dapeng
2026-03-24 0:41 ` [Patch v7 12/24] perf/x86: Enable XMM register sampling for REGS_USER case Dapeng Mi
2026-03-25 7:58 ` Mi, Dapeng
2026-03-24 0:41 ` [Patch v7 13/24] perf: Add sampling support for SIMD registers Dapeng Mi
2026-03-25 8:44 ` Mi, Dapeng
2026-03-24 0:41 ` [Patch v7 14/24] perf/x86: Enable XMM sampling using sample_simd_vec_reg_* fields Dapeng Mi
2026-03-25 9:01 ` Mi, Dapeng
2026-03-24 0:41 ` [Patch v7 15/24] perf/x86: Enable YMM " Dapeng Mi
2026-03-24 0:41 ` [Patch v7 16/24] perf/x86: Enable ZMM " Dapeng Mi
2026-03-24 0:41 ` [Patch v7 17/24] perf/x86: Enable OPMASK sampling using sample_simd_pred_reg_* fields Dapeng Mi
2026-03-24 0:41 ` [Patch v7 18/24] perf: Enhance perf_reg_validate() with simd_enabled argument Dapeng Mi
2026-03-24 0:41 ` [Patch v7 19/24] perf/x86: Enable eGPRs sampling using sample_regs_* fields Dapeng Mi
2026-03-24 0:41 ` [Patch v7 20/24] perf/x86: Enable SSP " Dapeng Mi
2026-03-25 9:25 ` Mi, Dapeng
2026-03-24 0:41 ` [Patch v7 21/24] perf/x86/intel: Enable PERF_PMU_CAP_SIMD_REGS capability Dapeng Mi
2026-04-25 2:01 ` sashiko-bot
2026-03-24 0:41 ` [Patch v7 22/24] perf/x86/intel: Enable arch-PEBS based SIMD/eGPRs/SSP sampling Dapeng Mi
2026-04-25 3:08 ` sashiko-bot
2026-03-24 0:41 ` [Patch v7 23/24] perf/x86: Activate back-to-back NMI detection for arch-PEBS induced NMIs Dapeng Mi
2026-04-25 3:31 ` sashiko-bot
2026-03-24 0:41 ` [Patch v7 24/24] perf/x86/intel: Add sanity check for PEBS fragment size Dapeng Mi
2026-04-25 3:53 ` sashiko-bot [this message]
2026-03-24 1:08 ` [Patch v7 00/24] Support SIMD/eGPRs/SSP registers sampling for perf Mi, Dapeng
2026-03-25 9:41 ` Mi, Dapeng
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=20260425035339.8032DC2BCB2@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dapeng1.mi@linux.intel.com \
--cc=linux-perf-users@vger.kernel.org \
--cc=sashiko@lists.linux.dev \
/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