From nobody Sat Feb 7 07:30:52 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 BFC8024BD03 for ; Mon, 19 Jan 2026 18:50:05 +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=1768848607; cv=none; b=qfQ90yZ1fjKiIChteqb0JSdWxHSPlIOd4ftm/Lqcmb/VR7gJkP57P1H8TKcekHkO0vTfeJOx94N24ntBreh5NlYvbuYajdTghOO/ab2W5N9GqsN55TJcE1ko3BFGB6N4i52S1ShIdKnFot7+SCKPLjmne9lek9bld8DnyvQXtA0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768848607; c=relaxed/simple; bh=sRvXaccqEOLfZpTQKHnPoLP/VGpY5fCf0tZuR1ywRxM=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=LAKQiT33PYNuqH3h5qicg8WfsYqmMU7vWkL47cAVrchOj3LFfO93xMrh6k7TQQ7QJC8kzT9lLp66lQXNqSYsC+Tm7ITLjTEQonv5JzQjxWCScZzG1/Bt77AMwvADBLl1RdIzdez++wPtIb3nKCF+p575fo2aSDdxwvNsL4t2fic= 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=bYUb0NJ+; 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="bYUb0NJ+" Received: by mail-dy1-f181.google.com with SMTP id 5a478bee46e88-2b6bf6adc65so4382737eec.0 for ; Mon, 19 Jan 2026 10:50:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=asu.edu; s=google; t=1768848605; x=1769453405; 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=oM7YwFaYfpzWin0JEzaV48zpKRTcuAip989AP9etaf0=; b=bYUb0NJ+rT3f1MKaGfsWepTwD1k5aNQaPYu5Ho7mGdZa++i4I+zhL++xOkVmLGNpDi K1jaMFOORDnKGKRhaI6HKFO7q1JSoWsIN51uFSKaTI+cn5tVJ7hPbG0D5ivkLSPJGSEd WM//7XTOOE+5ENZNh0F3Yemb7RoyHLoUHx+T0NBFeRDVTdgIIpJOj9SVtwl0BfpMRF/K 6IEL0dXPpl+bx85ANiXw1GLYdpkrv3f5yJDX5xhrzL7Rc3LuevYCITVGmoXgVVrjhE1R u5Dii+CYKPLYngQhbwvh02WenlQjxoyrqNH/eQy4tUC+9HxbxWy5h3OdYfheGSkkserx q/Sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768848605; x=1769453405; 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=oM7YwFaYfpzWin0JEzaV48zpKRTcuAip989AP9etaf0=; b=vbHbmA/6ypuBZHy4oKDPKsPfY3TfC9F8RaBTwYYREA4F02wR8kEJ6B2BpqQkGuY6Jk zdYGp5USaVBIKhawdTYJSlQ/4NhOTM+rIXNuHqwwwR8Uy/puYYDVSw/MsbgMMNSoxbJ7 KIheJbfxIeH6ULx/nIvte43+gZK5GdrakqRVeciNK8so5DQLKUU0sgIZecDL2CannfQK Uq7HasRLBIExMY9EMvxG7/dSsK45FOa2HR2WI3T0+YTTFUZk2fBLe90PL4NFFd5mRPTc aai2ZWMrd2uogT757Ani07cFr/8aFzkPzIoJiBuqXdSKpYOr55fBbzyKjFfl9+Xd3G6A j/MA== X-Forwarded-Encrypted: i=1; AJvYcCVDMPEa+zLp5sZN/yER0DtoHYyKMaLb7SJ1RLA3iftzvkOoXndD99qcXWlr8vn46C3VSYzaS1RBYLM4oWo=@vger.kernel.org X-Gm-Message-State: AOJu0Yw1XJYu6Tzb2o2NLSyXoIeGzBCQDWlvRU4gp7LI23diM2oYwJeG Y9VXpmHa06pqSvz91kPZotlDVMzvMz5ymVS2EuPCvNxscelu1eKgXOQz1w4E46D4Yg== X-Gm-Gg: AZuq6aLJEaDTm7Eut3uMwlrZHltgpcvKIvcvAR6HIrBOXznHrjN1wXEqfpAtOSS8g28 0dkyjqEcl9oJ+LkT4gVKmemHaeEqpY0nFdbs+Ba0BfIlWLxaQjz/AhskETcwQ/nzFMO6EOyzuJw AB2+qn+MT66c6jat0Dg8WA/twCpk7Xb6Hev0hWo17rbAaaNeWVq7R5b6cPD53k1QhmrFIX/EMe9 2ZfzV3KGZP91gBS9CBDNIGXK+SKWWZhsUef/L1B94vUf7OUR7QBJ6sgxFzMsArjG7i43wLBQbX1 J30w5ZyEstBVZrw150ifMXnOfzD43LrVZcKa4LsELp7dltUzJu3whHBbVfxAxCyh4A0UldwtvQG PX4kg0vfD6GKY2RgEO8zRc0nxte71ydt9kB4bif//RrFTUDYmf/O/jNwfcReetZT3/msOteuNmo mH5UHbq58cfWZ8SuM+UxnJ/2BBAHP7uvnUmU7Ac4ApdBJ16z4jMg== X-Received: by 2002:a05:7300:54d:b0:2a4:3593:ddd9 with SMTP id 5a478bee46e88-2b6b46c69ebmr8731975eec.6.1768848603315; Mon, 19 Jan 2026 10:50:03 -0800 (PST) Received: from will-mint.dhcp.asu.edu (209-147-139-190.nat.asu.edu. [209.147.139.190]) by smtp.googlemail.com with ESMTPSA id 5a478bee46e88-2b6b34c1177sm15926209eec.7.2026.01.19.10.50.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Jan 2026 10:50:02 -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 , Lorenzo Stoakes , Thomas Gleixner , linux-perf-users@vger.kernel.org (open list:PERFORMANCE EVENTS SUBSYSTEM), linux-kernel@vger.kernel.org (open list:PERFORMANCE EVENTS SUBSYSTEM) Subject: [PATCH v3 RESEND] perf: Fix refcount warning on event->mmap_count increment Date: Mon, 19 Jan 2026 11:49:56 -0700 Message-Id: <20260119184956.801238-1-whrosenb@asu.edu> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260106203547.38354-1-whrosenb@asu.edu> References: <20260106203547.38354-1-whrosenb@asu.edu> 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 also 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 I also wanted to check my understanding of the race with perf_mmap_close() to double check this patch will not cause an issue. perf_mmap_rb() should always hold the event->mmap_mutex, so there should be no race on event->mmap_count with perf_mmap_close()'s refcount_dec_and_mutex_lock(). If there was a race, we would risk returning -EBUSY when we should "continue as if !event->rb." =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