From nobody Thu Apr 9 12:49:57 2026 Received: from mail-dy1-f174.google.com (mail-dy1-f174.google.com [74.125.82.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B9804199920 for ; Mon, 9 Mar 2026 01:42:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.174 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773020545; cv=none; b=ZaQgyDRHKFzm9n9DqTINiOTIapLjoBHEFBdwwfXS7TD5ZIV8rA+IIUGNC3xCvsNKKEfAORvl4eQ/UmUi8rZ7RFl3qPjBWKXgaAHzYKKHjq7Ya5Th6G0uPztlWp4A7cgwKtAjgBwM4cE5uXNymeRTYQn/piUp1A0BRxy9uql/KOE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773020545; c=relaxed/simple; bh=7eIRj2vMmWqWMoz7ARzhm3Vzc/DWOI+G7T8MQ6zGMtE=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=BFYTIwxPeKSS6d0MH20R9kA7aXfagxgEakXSIAvQfGhpAjezvhMUZ3eJ00NYiWHyrAtVyR921S8aWP+s5TKQrxNrsI5SEpy/95nbWYNpyYplbPY2H7Bo2EHgNkRJiFuVVFbOGgpXN1XfCm9R8kpgKy4qkpGIIB/HfL0gKZsNtJA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=kv7uWuCa; arc=none smtp.client-ip=74.125.82.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="kv7uWuCa" Received: by mail-dy1-f174.google.com with SMTP id 5a478bee46e88-2b4520f6b32so12794436eec.0 for ; Sun, 08 Mar 2026 18:42:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773020543; x=1773625343; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=PUaRsNVwFauHrwZp2JYwojAS9B/lt2+UrlKTaGTgnNQ=; b=kv7uWuCaIam9J6WC4zuL1b9Eu9Dk9L0xRFjOnwp3tR224KRLJVmYQfaIiZbgy6k2hZ ovNFTVAY3wzBYCrtdHH4F7k09FBjrR7zqOQlhSvz0yzZgayAU4P/jzpmQpVvTLgBPLlL GZVb0awOqE+waEm87qsKeM+t8GVoiToLIh9VSCcohPgKV8pyACkhyyqdJXEea2796Ttc rAnbhNqFtK5pVJP5sJV+HV8R9/KcSkPDVVbEVFvms5uf+3ZExJ1HTayL3yRb9AbmcWgs oJs6vSt8eLbI+u31zu3Kn9obq+L7GbscWXNPI7dZas7/9YZMYGwURW6QdoEIyanrABn4 V3rA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773020543; x=1773625343; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=PUaRsNVwFauHrwZp2JYwojAS9B/lt2+UrlKTaGTgnNQ=; b=VNzRADX3qj3n/Ly/VBouS1OEo7fO4aWMGDsaFDUsGAjJuKJtzE9fD8nczMnqJnxzZn 2T9H+RiD0ClEuEpV7LO9kJ6HivOV8/30C30yAJs1HRadLy+iWFiRWTTBj5Td/rGWYzHt P4hQ9rXurj9iBk9QwEX5SKHOtOMhd/qa92I6NgJUqn6/lT8aBgTKpGYbQjhkWko/6UOR CkasNWvSyxcMMwgPwg8AXs8OXiNH7bKc/oi0jLCX7id7yJ9f1pwTP6ZpjAu6J11LXLmC 9PgFeamM3e9Lo89lCZbHlWUUdR9kQn7PF/f4ZZohu3o5ouhOtKRpHUGYGfKLE/Ke18/O 737A== X-Forwarded-Encrypted: i=1; AJvYcCU5Llc5sL2DyQec9TTXEUOWbyC8cJ7UYx9lJ6i100wnjdaEdTbNLZF8nyBgEvPR9bRst6Jo4obVWH1bg0s=@vger.kernel.org X-Gm-Message-State: AOJu0YxgsfuQwZgIvO8+/m/Ltgk6n0NXc5vwzk/4zq1Da+63QyaWJIyr zumiurWe+VlMfkZmjQ2f0ldcVZdirJ9O2y+ta+d6DBLMra00EZ4cUvUV X-Gm-Gg: ATEYQzyRb4ccQH8MFxZ1eH90B/TvEdt2MdT/AnFnezlFjD2iSBF4ZoRsayaM1q2V51y /LcTO5nlIc6ebMRp0DGjzRokshcUmjN38uITmcmuOSp48una5CV/wlBp27pQBKmALqM08hB0qPz bj6OSllsaI8HVJBoI6rNhfRAIRltk9b5EJ2iVATolLcmV7p+pxcJhl86g6COwgbrzzVL4Uxu0Do BM1Gal2s8mShttS7FlBNZdKC6WYWIFOT6GyqHSmjDTQwFY++N0SPds9UX75ldyZBQnqLeahG8jx KmktFdg7hctxteOO5mlMzsdtS0T+d3nT5k1PSlf5zGaKmGojyvyU9q2ID+D2PwfpxwHG7cCobak OUlwLFwur/V/uKlmQR12T5Nodr+iFDHeLVuxvEMMBMWmeFbJvTRQCzEVUcddcjj5eInBnAz1PuF E7PyFm3hW9avc1Ev2ium8/6Q2CnLkSoilqcHTJzKPCwK+6jZ8= X-Received: by 2002:a05:7300:cd90:b0:2ba:8496:498 with SMTP id 5a478bee46e88-2be4de8e32amr3293507eec.7.1773020542692; Sun, 08 Mar 2026 18:42:22 -0700 (PDT) Received: from homelab.. (ip72-200-102-19.tc.ph.cox.net. [72.200.102.19]) by smtp.googlemail.com with ESMTPSA id 5a478bee46e88-2be6df8a348sm1367736eec.30.2026.03.08.18.42.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 08 Mar 2026 18:42:21 -0700 (PDT) From: Oliver Rosenberg To: Cc: olrose55@gmail.com, Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , James Clark , Thomas Gleixner , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Ravi Bangoria , linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] perf_events: fix array-index-out-of-bounds in x86_pmu_del Date: Sun, 8 Mar 2026 18:41:30 -0700 Message-ID: <20260309014215.3871484-1-olrose55@gmail.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Vulnerability Description: There exists a KASAN:wild-memory-access and an array-index-out-of-bounds (-1 index) in x86_pmu_del(). When a cross-PMU event group is created where the group leader is a PMU type that does not have txn implemented then the cpuc->txn_flags for the siblings are not set because only the group leader's pmu->start_txn() is called and in the case of not being implemented it is set to perf_pmu_nop_txn(). The events are still attempted to be processed as a group, when one of the x86 PMUs errors out, cpuc->txn_flags is not set and event->hw.idx is not set. The x86_pmu_del() function expects event->hw.idx not to be set when events are batched and not yet enabled during a transaction so the function checks the cpuc->txn_flags to skip the array-index-out-of-bounds. However, when an event errors out and the group events are not enable here, cpuc->txn_flags is not set and event->hw.idx is -1 so we do not skip the uses of event->hw.idx which causes an array-index-out-of-bounds. Vulnerability Reproduction (POC): static int peo(struct perf_event_attr *a, int g) { return syscall(__NR_perf_event_open, a, 0, -1, g, 0); } int main(void) { struct perf_event_attr raw =3D {}, bp =3D {}; int fds[64], n =3D 0, leader; raw.type =3D PERF_TYPE_RAW; raw.size =3D sizeof(raw); raw.config =3D 0x76; raw.exclude_kernel =3D 1; leader =3D peo(&raw, -1); if (leader < 0) return 1; while (n < 64 && (fds[n] =3D peo(&raw, leader)) >=3D 0) n++; for (int i =3D 0; i < n; i++) close(fds[i]); close(leader); if (n <=3D 0) return 1; bp.type =3D PERF_TYPE_BREAKPOINT; bp.size =3D sizeof(bp); bp.bp_type =3D 4; bp.bp_len =3D sizeof(long); bp.exclude_kernel =3D 1; bp.inherit =3D 1; leader =3D peo(&bp, -1); if (leader < 0) return 1; raw.inherit =3D 1; if (peo(&raw, leader) < 0 || peo(&raw, leader) < 0) return 1; for (int i =3D 0; i < n; i++) if (peo(&raw, -1) < 0) return 1; if (fork() =3D=3D 0) _exit(0); wait(NULL); return 0; } POC Explanation: The POC first fills the CPUs PMU events with x86 raw PMU events (type 4) to set up the group scheduling to fail and trigger the bug, it then creates a cross-PMU group with BREAKPOINT (type 5) as the group leader and 2 x86 raw PMU siblings. The first sibling is added but batched and not enabled, the second sibling fails on add because we exceed the max number of PMU events for the cpu. This triggers the cleanup of the first sibling for which cpu->txn_flags is not set and event->hw.idx=3D-1 since sibling 1 was not enabled. This triggers the bug when event->hw.idx is used as an array-index-out-of-bounds in x86_pmu_del(). Suggested Fix: The suggested fix is to add a check in x86_pmu_del() to verify event->hw.idx is set before using the value. If it is not set then jump over the use of event->hw.idx and proceed with cleanup. Fixes: bd2756811766 ("perf: Rewrite core context handling") Signed-off-by: Oliver Rosenberg Reported-by: Oliver Rosenberg Reviewed-by: Ian Rogers --- Notes: This patch fixes the symptom and prevents the array-index-out-of-bounds caused by the dangerous use of hw->idx when it is not set. I was not su= re if it may make sense to also solve the root cause of the issue which is cpuc->txn_flags not being set for PMU events in a group where the group leader does not implement transactions, or if this would require a rede= sign to how group events are process and have potential performance degredations. arch/x86/events/core.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c index 03ce1bc7e..7474b2d66 100644 --- a/arch/x86/events/core.c +++ b/arch/x86/events/core.c @@ -1655,6 +1655,9 @@ static void x86_pmu_del(struct perf_event *event, int= flags) if (cpuc->txn_flags & PERF_PMU_TXN_ADD) goto do_del; =20 + if (event->hw.idx < 0) + goto remove_from_list; + __set_bit(event->hw.idx, cpuc->dirty); =20 /* @@ -1663,6 +1666,8 @@ static void x86_pmu_del(struct perf_event *event, int= flags) x86_pmu_stop(event, PERF_EF_UPDATE); cpuc->events[event->hw.idx] =3D NULL; =20 +remove_from_list: + for (i =3D 0; i < cpuc->n_events; i++) { if (event =3D=3D cpuc->event_list[i]) break; --=20 2.43.0