It's possible for userspace to control event_id. Sanitize event_id when using it as an array index, to inhibit the potential spectre-v1 write gadget.
This class of issue is also known as CVE-2018-3693, or "bounds check bypass store". Found by smatch. Signed-off-by: Mark Rutland <mark.rutl...@arm.com> Cc: Peter Zijlstra <pet...@infradead.org> Cc: Ingo Molnar <mi...@redhat.com> --- kernel/events/core.c | 2 ++ 1 file changed, 2 insertions(+) For Arm CPUs, more details can be found in the Arm Cache Speculation Side-channels whitepaper, available from the Arm security updates site [1]. Mark. [1] https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability diff --git a/kernel/events/core.c b/kernel/events/core.c index 8f0434a9951a..eece719bd18e 100644 --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -8155,6 +8155,7 @@ struct static_key perf_swevent_enabled[PERF_COUNT_SW_MAX]; static void sw_perf_event_destroy(struct perf_event *event) { u64 event_id = event->attr.config; + event_id = array_index_nospec(event_id, PERF_COUNT_SW_MAX); WARN_ON(event->parent); @@ -8186,6 +8187,7 @@ static int perf_swevent_init(struct perf_event *event) if (event_id >= PERF_COUNT_SW_MAX) return -ENOENT; + event_id = array_index_nospec(event_id, PERF_COUNT_SW_MAX); if (!event->parent) { int err; -- 2.11.0
