All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Vinay Belgaumkar" <vinay.belgaumkar@intel.com>
Cc: intel-xe@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] perf: Fix null pointer access in is_include_guest_event()
Date: Fri, 28 Aug 2026 01:00:40 +0000	[thread overview]
Message-ID: <20260828010040.D2E831F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260828004208.3906054-1-vinay.belgaumkar@intel.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] A NULL pointer dereference occurs in `__perf_event_read_cpu` when reading a revoked event via BPF, leading to a kernel panic.
--

commit c13911e3a6c666fcef554ee81ad9104c9e6e198c
Author: Vinay Belgaumkar <vinay.belgaumkar@intel.com>

perf: Fix null pointer access in is_include_guest_event()

This commit fixes a kernel panic during PMU event unbinding by adding a
null check for event->pmu in is_include_guest_event() and ensuring
mediated_pmu_unaccount_event() is called in __pmu_detach_event().

> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index a6c8e38a31104..e6bc08c7ba3e7 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
[ ... ]
> @@ -13002,6 +13005,8 @@ static void __pmu_detach_event(struct pmu *pmu, struct perf_event *event,
>  	exclusive_event_destroy(event);
>  	module_put(pmu->module);
>  
> +	mediated_pmu_unaccount_event(event);
> +
>  	event->pmu = NULL; /* force fault instead of UAF */

[Severity: High]
This is a pre-existing issue, but does setting event->pmu to NULL here
expose a missing check in the BPF read path?

If a userspace process places a PMU event (which supports scopes) into a BPF
PERF_EVENT_ARRAY map, the event remains alive in memory due to the BPF map
holding a reference. When the PMU device is unbound, this function sets
event->pmu = NULL and marks the event as PERF_EVENT_STATE_REVOKED.

If a BPF program subsequently calls bpf_perf_event_read() on this event,
it invokes perf_event_read_local(). Since perf_event_read_local() does
not appear to check if the event has been revoked (unlike perf_read() or
perf_poll()), it unconditionally proceeds to __perf_event_read_cpu():

kernel/events/core.c:perf_event_read_local() {
	...
	event_cpu = __perf_event_read_cpu(event, event->cpu);
	...
}

Because event->group_caps retains the PERF_EV_CAP_READ_SCOPE flag,
__perf_event_read_cpu() attempts to evaluate event->pmu->scope:

kernel/events/core.c:__perf_event_read_cpu() {
	...
	const struct cpumask *cpumask = perf_scope_cpu_topology_cpumask(event->pmu->scope, event_cpu);
	...
}

Can this trigger a kernel panic due to a NULL pointer dereference when
event->pmu is unconditionally dereferenced?

>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260828004208.3906054-1-vinay.belgaumkar@intel.com?part=1

  parent reply	other threads:[~2026-08-28  1:00 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-28  0:42 [PATCH] perf: Fix null pointer access in is_include_guest_event() Vinay Belgaumkar
2026-08-28  0:54 ` ✓ CI.KUnit: success for " Patchwork
2026-08-28  1:00 ` sashiko-bot [this message]
2026-08-28  1:33 ` ✓ Xe.CI.BAT: " Patchwork
2026-08-28  2:40 ` ✓ Xe.CI.FULL: " Patchwork

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=20260828010040.D2E831F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=vinay.belgaumkar@intel.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.