From nobody Sun Feb 8 07:22:24 2026 Received: from mail-dl1-f48.google.com (mail-dl1-f48.google.com [74.125.82.48]) (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 C523E233704 for ; Mon, 29 Dec 2025 21:04:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.48 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767042243; cv=none; b=EjOHOb8XsIV75yQYKuCiiPrewkphn/CaHEQDEPN1V1ps/57sitj8ZSLd8BW7WWbuBbsUeObQqcdsHNnf/AaZO+cB8lxSZz6JFvGIUW81FMZBHtmoSlfJZfbxPQJljoukILuZtPjbVbPL4rEzmH4hZBKKe+aUC9bWhpVR3e8pE3w= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767042243; c=relaxed/simple; bh=6Ks0xRzyWcD5nHqKH8+WHYZ2GiW1MN9WIRQUrkwV6HE=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=mcHPWelA3mg8N85rVUYTOZfgWtMaC6EW03CV/1wavD8nv1JCap2eh8ZaxE88dKqMENhZa94BD9vEt0rMSr9TUcObMzR3MPJUpf0D/CEa8pPf/f4vh98OY97loAoz4DzC5RV5aL4W2+S7NaH3rfPb59wR8bz6zPz37dxIsguWvow= 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=QLTPyIzy; arc=none smtp.client-ip=74.125.82.48 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="QLTPyIzy" Received: by mail-dl1-f48.google.com with SMTP id a92af1059eb24-121b251438eso2257838c88.0 for ; Mon, 29 Dec 2025 13:04:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=asu.edu; s=google; t=1767042240; x=1767647040; 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=dMXmmIwHZ/4Otl6o+BH1rACcqNy1K+ueCZiBvlBf+dM=; b=QLTPyIzyVNTqlsmI191ZlFVxi54xzeXh1nFeGrb2Ecdqq+YEtqDkgFoQrM+Z4uinXy 8U16Oa8hrtaDVHiqv4usmYGp7j2WwknCwz5Hc9sDf3+9mfPC6ldxmt5O52N0rTBLD1i0 AwU/Z3LW92jzjKjwoy+CfForPMvGuqo2MMS5WX2igGPxx3gWHi5z0BcQ/P7XWCtMH6td Ro2lhDUAcoDOt+z86cKxpNQeS79JtaR283u5+gZUmuTCBI2pk2U1cnNa20aQfqSAjFEn 1CUK2DySxKsDKZKKb8Rpo4k9I2Gcw9jH5IlwktohhMfwJQoQEYjedCW2xmo1euMf3O5m SrPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767042240; x=1767647040; 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=dMXmmIwHZ/4Otl6o+BH1rACcqNy1K+ueCZiBvlBf+dM=; b=h+Wqv3bUKP18CwbarR1utSn7r3z82hIk8LIIl0yYZMZnsTCOd0PcWCNCGvBcTuz2xG cjtIVCGj6s0KJmqWxWIzfl8hvB8k8rBAIC1ESVDslONovPvodxKGsnGhX69ELWWJg38F JcOVsn28TV20/l6HmScwwAZ9YUysb92cGKG98KIBTbkrmO/XEKuoWerafDlObkUTGD9f 4hXiAkz7X7+bIcsIfV8V53UgvmrwLn5wBbSTfMo7OXSV43X/fDnPtsSSY7RqPwj474gS uOO+xEfEMXpc1AxMJbGU2fLnMtpCq4JLls+KL+zNZFO5F8wzPm8Jh9WedcwNf6uMf/9M 7YFg== X-Forwarded-Encrypted: i=1; AJvYcCXYiZRKuJf2iHOEo6TyuglTAjLudUYkTF2WiYrxgCe6Y895hwLZafD2M0gacKBShSN/MrjhUAZumxAsasQ=@vger.kernel.org X-Gm-Message-State: AOJu0YzoQagw2DEKPXfaXvQuCRJru3qUAcXoOdnbMA8VwIxTd67izn67 R0Uuamk6IkU2q8fpQ7MTtCzNr7apFmX1W7eLrP0ImFqIuJXe+cfag92Zaq3xxhUuEw== X-Gm-Gg: AY/fxX4kPGbHKvPUm4AehEagDNLosxdwjkk6aD6NIUHNxIATfeknkwDJw78fV4j005K yW8PJWTFBGWEf39+XjQMrHHtvb+C6cHNjMDvZYvRDI9PPLPOcjGi2umg36w9JPon9RGtwpNFUlw wVODT/K64A7jKf8wGkJgZOHYF2mSBZwJ0WAbiWLNDmAVZ68NpQ/WJJmjV35D+BC4R01tujjft+X QvpezqLls49ea0RiHz5t13QwkX+ZKEQEzJCLKD92bYANi/tRIX+kTt0tlN1S55xkAgzDykxOJHJ fdiMLmQR2IzJ+SUfxvRTFnwHqxgkJBapUiFNQt6pvNMeuvxtztpyMXfYbjB8FrTUlk5bnke6h3r iNWLLqKysKFI6bqilyJHEjweY0lHSCmq1skfL06aGBapM0pp2nQbj7OP3/curX9FzwgEto4hdXr C+0316wb3/IDhETWXXbaBrnRKga9vR3MVcDIRLZd/GXU61fm0DPQ== X-Google-Smtp-Source: AGHT+IHm06cgGI7TRQvfy27jGwQ2mVdrbCBdorkVBs/wQMFeuTn7eDIadqhVNbcrNoV5fzO3gUfjig== X-Received: by 2002:a05:701b:240d:b0:11d:fc25:af63 with SMTP id a92af1059eb24-1206194371emr25133278c88.11.1767042239815; Mon, 29 Dec 2025 13:03:59 -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 a92af1059eb24-121724dd7f5sm120632754c88.5.2025.12.29.13.03.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Dec 2025 13:03:59 -0800 (PST) From: Will Rosenberg To: Cc: Will Rosenberg , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , James Clark , linux-perf-users@vger.kernel.org (open list:PERFORMANCE EVENTS SUBSYSTEM), linux-kernel@vger.kernel.org (open list:PERFORMANCE EVENTS SUBSYSTEM) Subject: [PATCH] perf: Fix refcount warning on event->mmap_count increment Date: Mon, 29 Dec 2025 14:03:55 -0700 Message-Id: <20251229210355.65732-1-whrosenb@asu.edu> X-Mailer: git-send-email 2.34.1 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. Account for the case when event->mmap_count =3D 0. This patch goes against the design philosophy of the refcount library by re-enabling an empty refcount, but the patch remains inline with the current treatment of mmap_count. Signed-off-by: Will Rosenberg Tested-by: Yi Lai --- Notes: I also have a related concern about code that handles the mmap_count. In perf_mmap_close(), if refcount_dec_and_mutex_lock() decrements event->mmap_count to zero, then event->rb is set to NULL. This effectively undos our output_event copy. However, is this desired behavior? Should event->rb remain unchanged since it may still be mmap-ed by other events and can still be used? kernel/events/core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/events/core.c b/kernel/events/core.c index 376fb07d869b..49709b627b1f 100644 --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -7279,7 +7279,8 @@ static int perf_mmap_rb(struct vm_area_struct *vma, s= truct perf_event *event, * multiple times. */ perf_mmap_account(vma, user_extra, extra); - refcount_inc(&event->mmap_count); + if (!refcount_inc_not_zero(&event->mmap_count)) + refcount_set(&event->mmap_count, 1); return 0; } =20 base-commit: 538254cd98afb31b09c4cc58219217d8127c79be --=20 2.34.1