From nobody Sun Feb 8 16:11:45 2026 Received: from mail-dy1-f181.google.com (mail-dy1-f181.google.com [74.125.82.181]) (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 4D67D340DA7 for ; Tue, 6 Jan 2026 20:35:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.181 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767731752; cv=none; b=Gfv5k9R2eK1vO7D5W6byhYdBupK5XgEbCSIsdkBTKJ9bt7yrgNuGNpylpucKBrG/51IdMIyQTWlswSVQ4D/Cf5SVNRjZeJ1Kz1UICLC/6i9rh/6D4PCqe9TMsxRzQi14E+z9bNClfye729A5+9P1EMaZBkd2wnJSGPl3OxSpmto= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767731752; c=relaxed/simple; bh=Sw9ZsVAw2dBIXrT5662jaBGxj31pAS7nwA/5PmMq42M=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=LlebY/QA5cMOeGVArTzDBX3e6xhIAgridCxVNL17TF8GLOkA94KoLaamZH9cTRJNuVzj2kFNguQqhiP5x0U4Yzqf9EuopdDKQJcf5+AxJ6r5n6OowIAqrvLrdOMh0wjBOS7uOZtu/0KHct2uw+Xq5Lyorsbyxy55tgwu4nErEt4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=asu.edu; spf=pass smtp.mailfrom=asu.edu; dkim=pass (2048-bit key) header.d=asu.edu header.i=@asu.edu header.b=Aa5SSJ0O; arc=none smtp.client-ip=74.125.82.181 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=asu.edu Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=asu.edu Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=asu.edu header.i=@asu.edu header.b="Aa5SSJ0O" Received: by mail-dy1-f181.google.com with SMTP id 5a478bee46e88-2ae2eb49b4bso1108197eec.0 for ; Tue, 06 Jan 2026 12:35:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=asu.edu; s=google; t=1767731750; x=1768336550; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=5HMrXNeVRa4McHU4PJIt7hXSHEgXBBRdiELEZFy8OpA=; b=Aa5SSJ0OvqyLo9XVwG6cAjbHwQr0w14YhiweWMyhvMc5EX/ZnwRvLTQgj779HFvZyB oLuPcv1n0Eiozqw80Wwf4317fdiWQrBG30iPnlYCS99gL9M/x5NzTkhcBaymTwsISYo6 7hwu3c4phh8rMZqQBd8trRIAQtNkY7d0CjEQZHfZTJyCwtP0lfvPOoXS9bFgXcZYd9Rr AZezeUHoiNRMxCx/YOF57yoV79cFQb+DpIyPrd9wRxowKsY6vfNZnXz7etk4h3IX5Hb/ esPNfic59CjfE/x8UYE+/CGYKBZGt4KL/f53/CQRj0uROb6rbZZgW1vPu2EQYRWEpzAC NBlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767731750; x=1768336550; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=5HMrXNeVRa4McHU4PJIt7hXSHEgXBBRdiELEZFy8OpA=; b=br4LNUMLGq3ZnfLKKVqe3EA0No6XUVBAm8tG7gqPdj0URzI9z0Jca7T8kshc33wJb1 fcqROPS7HCAytQwB688GwPcRtgLJAG3ZDMyA1nqUuEAfJvSFG/bxzyNos7qBTiV1a3wd Mz6Up3z8tIbxDkwAafk6GcRCdVMLLOay0TD9Ay4fjf53eBRpvwNlCj0oltka/YBETDfF gRAQxXA5kI8IKV1KpMbnoiFEr7v57s+CuYsKYcFrTfaKuVIFZnzqLLuvrHwcwPuigqsn Yttfcou1nR0heVO0/wsSLY+GDjBeUfY2xxwK8GiSV1H31WETQAo08yLN113Ns5qTRRxY cN8w== X-Forwarded-Encrypted: i=1; AJvYcCW2nP0uZHVMOPC6KcEDdqNkuXrCoOlEuMP7yGE7Q3dmP0XNgFS5bOUTDdIyR9PaUO3CzNLD4tinOwZvW1I=@vger.kernel.org X-Gm-Message-State: AOJu0YzTZorjBr9GqRAmG2kPk5cAzBSTsreUNUL4C/wt3pwyVCyIzBw7 9nMvfq7sX2eNazLkHsiyw/EaeSErtUd+IihvDLpgyxnFfiuW6r+S4TEkDO20f+9jWg== X-Gm-Gg: AY/fxX5pgiVKK2CZubHN6mZ7XtkNqNXA+qnRNjtE60hiS7sMv8AMUxThW3NsH3rJ2gN W6lyvVqexZ6AIpVbWuy2t0IcdagXwVinoAmCrgDj3/GmyYOj3VK/OJbNXXI35VYfB9bX/RoryAY COdcrmqHoJYgwWpPevWD5kWaUKUJbZ1ZV+p4xFFL+U6hOeyFxP93Tr5eVfy/itBRHAMmFPTXx7e IjOI6exOI73hwQYX+0McuOBM5Ob4we3c9rrHxrVMzOShb39LV03Y7gspOHKh0gsciODSJcJPGGW eWApKu3U0zUPq0escePApZ1GqMiQbhub//UFx+wZ5BfHFw3YsSPfFYISqPuAqSUEF2irU89TzGZ dt5mu072FssU4J8t1dJkRxidYpZI8wGtuRLxzntUgtQMSbTqAlzsQg4psHvPcu0StbvVRky4JfN R9A6J0pDVSTigkFXuzWvHcBDTjQ0vuoQY= X-Google-Smtp-Source: AGHT+IF/kyhC5NGpJANw01FLuXvm3TOrclj3UN/7JZe09J5OirtBHLHRsxGcYY+3HD1Bsh60gv219Q== X-Received: by 2002:a05:693c:40db:b0:2af:cd0a:ef8c with SMTP id 5a478bee46e88-2b17d2c0ed4mr201763eec.36.1767731750294; Tue, 06 Jan 2026 12:35:50 -0800 (PST) Received: from will-mint.dhcp.asu.edu ([192.145.119.14]) by smtp.googlemail.com with ESMTPSA id 5a478bee46e88-2b170673bc0sm5251698eec.5.2026.01.06.12.35.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 06 Jan 2026 12:35:49 -0800 (PST) From: Will Rosenberg To: Cc: yi1.lai@linux.intel.com, Will Rosenberg , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , James Clark , Thomas Gleixner , Lorenzo Stoakes , linux-perf-users@vger.kernel.org (open list:PERFORMANCE EVENTS SUBSYSTEM), linux-kernel@vger.kernel.org (open list:PERFORMANCE EVENTS SUBSYSTEM) Subject: [PATCH v3] perf: Fix refcount warning on event->mmap_count increment Date: Tue, 6 Jan 2026 13:35:46 -0700 Message-Id: <20260106203547.38354-1-whrosenb@asu.edu> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260106093431.GA3707837@noisy.programming.kicks-ass.net> References: <20260106093431.GA3707837@noisy.programming.kicks-ass.net> 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" When calling refcount_inc(&event->mmap_count) inside perf_mmap_rb(), the following warning is triggered: refcount_t: addition on 0; use-after-free. WARNING: lib/refcount.c:25 PoC: struct perf_event_attr attr =3D {0}; int fd =3D syscall(__NR_perf_event_open, &attr, 0, -1, -1, 0); mmap(NULL, 0x3000, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); int victim =3D syscall(__NR_perf_event_open, &attr, 0, -1, fd, PERF_FLAG_FD_OUTPUT); mmap(NULL, 0x3000, PROT_READ | PROT_WRITE, MAP_SHARED, victim, 0); This occurs when creating a group member event with the flag PERF_FLAG_FD_OUTPUT. The group leader should be mmap-ed and then mmap-ing the event triggers the warning. Since the event has copied the output_event in perf_event_set_output(), event->rb is set. As a result, perf_mmap_rb() calls refcount_inc(&event->mmap_count) when event->mmap_count =3D 0. Disallow the case when event->mmap_count =3D 0. This prevents two events from updating the same user_page. Fixes: 448f97fba901 ("perf: Convert mmap() refcounts to refcount_t") Suggested-by: Peter Zijlstra Signed-off-by: Will Rosenberg --- Notes: v2 -> v3: Update patch to error out instead of incrementing. =20 Thank you, this is a much better solution. I was not thinking that the mmap itself was unintended. =20 I believe you are missing a "!" in your patch. After adding that, I tested the patch, and it fixed the bug. =20 Thank you for your help. kernel/events/core.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/kernel/events/core.c b/kernel/events/core.c index 3c2a491200c6..ac7f12560172 100644 --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -7273,6 +7273,15 @@ static int perf_mmap_rb(struct vm_area_struct *vma, = struct perf_event *event, if (data_page_nr(event->rb) !=3D nr_pages) return -EINVAL; =20 + /* + * If this event doesn't have mmap_count, we're attempting to + * create an alias of another event's mmap(); this would mean + * both events will end up scribbling the same user_page; + * which makes no sense. + */ + if (!refcount_read(&event->mmap_count)) + return -EBUSY; + if (refcount_inc_not_zero(&event->rb->mmap_count)) { /* * Success -- managed to mmap() the same buffer base-commit: 5d3b0106245d467fd5ba0bd9a373a13356684f6e --=20 2.34.1