From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj2-f12.google.com (mail-pj2-f12.google.com [74.125.227.140]) (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 89EE73D3B3 for ; Mon, 21 Sep 2026 00:33:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.227.140 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789950790; cv=none; b=EVfU/DDTmapBi0YOWoYNJzf3Wy27ADAnV46zkoR9Kl7NgUC4Kd3m1D+lETpTSwCxgumhEacQ+Dz4dUSS/36B4fo+SZbELYqHatDdeio3EPmPmyPgp+lAXz+6cxFYIZ4SMFoY8UDln79vSSodmb1rzOMrVPJepkhfxEftgS+CDQ4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789950790; c=relaxed/simple; bh=JuCBa24Q8mcK4IKnzSx3OFgFtgWwVjqbYpPpkFwtRIU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=lTT34Xjs9AiztsQRaAgrthAegfc/BYy4PmKFJMQVXMhKpaZsXRS7smo+JgM3owZK1L9ivbJY5HTKP/fwfm9ES7ccSsqA6s3LMxe8biC4A6aDHe7SEgOnAgU6ay5KjvZuivL24+x48v001pUudTuUAttm15SCsyhI4RCD8N/Wzeo= 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=JHZvwieB; arc=none smtp.client-ip=74.125.227.140 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="JHZvwieB" Received: by mail-pj2-f12.google.com with SMTP id d9443c01a7336-2d747ec6185so14446195ad.0 for ; Sun, 20 Sep 2026 17:33:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789950789; x=1790555589; 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:content-type; bh=rMRLgcYmgr1ReQQm9bu3ytCdU9X0QEixo1U1Eo8/PJA=; b=JHZvwieBH0u7ScD1d6le0c8i4r3zobbI8/gzbWKCwb6tYkQXHTncEAJZpRWJm0vm3+ nzTunqQzwLzXwgN714hKUEtbcJ7C/LUuaRkVf9xDx6PxcKpcWaUnv4t5pfKyRWIu46tj Uw3a275P4uAGyz/MSd09TQTWXSxmBA0nUWhiKLiXGwhJ9jeRbntTu6gKx96HY1sdDtev IRO1OfUHeyIyQm1eZZp0l16FbCRjU8Ok6R4hDWM40CBZKdLkRqDghgbWR4jvRtEDzOsV E/iUQQ8709WwV8O8wgMVVVpT6ov18Y21HK65w9VYMwWBZuqOhaonic4fVN9SzZXNaGXV 09vQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789950789; x=1790555589; 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:content-type; bh=rMRLgcYmgr1ReQQm9bu3ytCdU9X0QEixo1U1Eo8/PJA=; b=naxqXqxzMDJaqUkVjaLHFnY+lQhyCvxFyJmRba3wmquSogOfCCnwtIUv3SM4QdCxk4 2x0CygkFy0+zePAdqHmfZOI8ol8Xz5v4wqb0CqtfNPlXNKXp5zLuiEclxfJTCULekj/2 IDpj2i/CfljR2OeQu1RglZQ28+kRFTGlfbvVN+D/Y0fEkUufIFhAMgbkX6e+QsEyhHj4 I+UVaCv0l8iaYOm8JFD3SZrfwDpE1TLEP8a37vpptTT6Ia+vNEvZuV+babw74ElToM8H aqdIrTE7k1poCsFf6SuXnBRhfRWHba3jG2y5j22VYFDLTTdTNpFzTU9MFEpVbT1XfXFK HYyg== X-Forwarded-Encrypted: i=1; AKwUvBw7mNb76Wkm4qlVUPaqQ46aJ3stEQ39+Ru57tr7byU2nFRwsEzHOmg22GaVsYQ4ArW3H2sZou8sagk0V2U=@vger.kernel.org X-Gm-Message-State: AFuF++lhMxQHpBiZKxy0rWwMKX9m6bRduHKxdvqF4py5i/Svy/kytq9+ zfTN1TyIB2Jjvb9b6QN0uaqtIF1VAEQWbmEYQDb/sV8j7OfjKtRJxyrf X-Gm-Gg: AYBFou1OGQj6DALk0y2JSSkYHTua0MFg3ZoiIcvAfGzSZkWsm0tYhHw4x9tsIsYV/5b q2r4aq2HDSJzXyx6G6Fur8XO96q8NiQj2/K0aPG7rCZ1kly/I2onT/yjml3gKxgZBceL3Qm923g SDws2exmntGHVkwlFtrspzrTj7/mSlTpU+VA3UTPWaOTdItyBD92LBhMlyen4fOR7tgX6oig250 tJ9K4dWYggVeiW4DXaE8VdQ2vQG/WRPe8LTTmFrcRfk5LUjE58vxQDwQqiy4+viGDqG+gMjTndY k5e0PRj5qh/hetPb3oWB0GVl+wIFEGav8D+qIylzEVRkAeOQ+Gy9wfkp1Jo9tYpWKOhJeP62nLX hoOQ4706vhmyifAvGi9SmITHVPRPmT+fG0Jclrvkt5QgNAcqHPxWGBpGHEc9doxjxif+pRjLGHq 4pE8nX9MU1CpnqQWHDZf8TMRYvFw9GtnhlJCslfrsV8ZQyKW8i7kEgVrnxu02zKF3O5WigeMAPV sDYsbt+fhq3fzOI7C5ZnIFDyE2TSM0u0UdeLwix0e8si1imo/mQ0zAKR3xTei8zTPh3cAkqkCFq YXGx2bo/xQPTC74J5yjh X-Received: by 2002:a17:902:c948:b0:2d8:d4de:fa80 with SMTP id d9443c01a7336-2ddb1ab39edmr133532675ad.4.1789950788805; Sun, 20 Sep 2026 17:33:08 -0700 (PDT) Received: from phui-2.c.googlers.com.com (78.123.83.34.bc.googleusercontent.com. [34.83.123.78]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2df44673b36sm8566115ad.0.2026.09.20.17.33.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 20 Sep 2026 17:33:08 -0700 (PDT) From: Hui Peng To: Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim Cc: Mark Rutland , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , James Clark , linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org, Hui Peng , stable@vger.kernel.org Subject: [PATCH v2] perf/core: fix user->locked_vm leak on secondary mmap() Date: Mon, 21 Sep 2026 00:33:06 +0000 Message-ID: <20260921003306.426050-1-benquike@gmail.com> X-Mailer: git-send-email 2.55.0.1082.g2b9226bbc0-goog In-Reply-To: <20260919221728.3707189-1-benquike@gmail.com> References: <20260919221728.3707189-1-benquike@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Commit 0c8a4e4139ad ("perf/core: Further simplify perf_mmap()") hoisted `user_extra = nr_pages` ahead of the existing-buffer checks (`if (event->rb)` and `if (rb_has_aux(rb))`), and subsequently commit 5d299897f1e3 ("perf: Split out the RB allocation") and commit 2aee37682391 ("perf: Split out the AUX buffer allocation") carried `long extra = 0, user_extra = nr_pages` into perf_mmap_rb() and perf_mmap_aux(). As a result, when an already-allocated ring buffer (`event->rb`) or AUX buffer (`rb_has_aux(rb)`) is mapped again via mmap(), perf_mmap_account() is called with `user_extra = nr_pages` instead of `0`, charging `nr_pages` to `current_user()->locked_vm` on every additional mapping. However, perf_mmap_unaccount() and perf_mmap_close() only subtract the ring buffer's and AUX buffer's pages once when the final `rb->mmap_count` / `rb->aux_mmap_count` reference drops to zero. Consequently, every secondary mmap() + munmap() cycle on a perf event permanently leaks `nr_pages` in `user->locked_vm`, eventually exhausting `perf_event_mlock_kb` and `RLIMIT_MEMLOCK` (-EPERM) for that user. Fix this by only calling perf_mmap_account() when allocating a new ring buffer in perf_mmap_rb() or a new AUX buffer in perf_mmap_aux(). Tested in QEMU against Linux 7.3.0-rc3 with a standalone C reproducer running as an unprivileged user (UID 1000, RLIMIT_MEMLOCK=0, perf_event_paranoid=1) that opens a software perf event, maps a 65-page ring buffer, performs 10 secondary mmap() + munmap() cycles on the same event fd, and then unmaps and closes the event. On the unfixed kernel, subsequent perf_mmap() calls by UID 1000 permanently fail with -EPERM due to the leaked `user->locked_vm` (650 pages leaked), whereas with the fix applied `user->locked_vm` returns to 0 and subsequent perf_mmap() calls succeed. Fixes: 0c8a4e4139ad ("perf/core: Further simplify perf_mmap()") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Hui Peng --- Changes in v2: - Dropped the cross-MM `pinned_vm` / `rb->mmap_mm` (`mmgrab`/`mmdrop`) changes (which caused an RCU softirq context violation in `rb_free_rcu()` in v1, flagged by sashiko-bot) to keep this patch focused on the `user->locked_vm` leak on secondary `mmap()`. - Updated the `Fixes:` tag to `0c8a4e4139ad ("perf/core: Further simplify perf_mmap()")` and added QEMU reproducer test details to the commit message. kernel/events/core.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/kernel/events/core.c b/kernel/events/core.c index fe33fe15689d..8fc15239bd7e 100644 --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -7311,7 +7311,6 @@ static int perf_mmap_rb(struct vm_area_struct *vma, struct perf_event *event, * Success -- managed to mmap() the same buffer * multiple times. */ - perf_mmap_account(vma, user_extra, extra); refcount_inc(&event->mmap_count); return 0; } @@ -7399,7 +7398,6 @@ static int perf_mmap_aux(struct vm_area_struct *vma, struct perf_event *event, if (rb_has_aux(rb)) { refcount_inc(&rb->aux_mmap_count); - } else { if (!perf_mmap_calc_limits(vma, &user_extra, &extra)) { refcount_dec(&rb->mmap_count); @@ -7420,9 +7418,9 @@ static int perf_mmap_aux(struct vm_area_struct *vma, struct perf_event *event, refcount_set(&rb->aux_mmap_count, 1); rb->aux_mmap_locked = extra; + perf_mmap_account(vma, user_extra, extra); } - perf_mmap_account(vma, user_extra, extra); refcount_inc(&event->mmap_count); return 0; -- 2.47.3