Skip to contentSkip to conversation

perf: Fix mmap replacement ring lifetime race

PATCH Superseded David Lee 2 participants 2 messages Jul 31 – Aug 2 perf events

v1 of 2 Superseded Latest is v2 →

lore
Share & tools
lore

David Lee

author
#0 lore raw

PATCH 1/1 perf: Fix mmap replacement ring lifetime race

perf_mmap_close() drops the ring-local mmap_count before serializing with perf_mmap() through event->mmap_mutex. When the last mapping is being closed, a concurrent mmap can therefore observe a nonzero event->mmap_count and a zero rb->mmap_count.

In that case perf_mmap_rb() detaches the old ring, installs a replacement, and resets event->mmap_count to one. The old close then consumes that replacement count and detaches the new ring. Its pages can consequently be freed while the replacement VMA still maps their PFNs.

Take event->mmap_mutex before updating either count. This makes the ring-local and event-global count transitions atomic with respect to perf_mmap(), so a replacement cannot be installed until the old close has detached its ring.

Fixes 59741451b49c ("perf: Identify the 0->1 transition for event::mmap_count")

Bug found and triaged by OpenAI Security Research and validated by Trail of Bits.

Assisted-by Codex:gpt-5.6-sol gpt-5.5-cyber

---
Trail of Bits has a reproducer for this bug that triggers a kernel panic and can share if needed.

 kernel/events/core.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)
kernel/events/core.c +9 -1
index ba5bd6a78..f93327c76 100644
@@ -7053,11 +7053,19 @@ static void perf_mmap_close(struct vm_area_struct *vma)
 		mutex_unlock(&rb->aux_mutex);
 	}
 
+	/*
+	 * Serialize both count updates with perf_mmap() so they cannot
+	 * refer to different ring buffer generations.
+	 */
+	mutex_lock(&event->mmap_mutex);
+
 	if (refcount_dec_and_test(&rb->mmap_count))
 		detach_rest = true;
 
-	if (!refcount_dec_and_mutex_lock(&event->mmap_count, &event->mmap_mutex))
+	if (!refcount_dec_and_test(&event->mmap_count)) {
+		mutex_unlock(&event->mmap_mutex);
 		goto out_put;
+	}
 
 	ring_buffer_attach(event, NULL);
 	mutex_unlock(&event->mmap_mutex);
Signature · 1 line
2.53.0
#1 lore raw
Quoted 6 lines · On Friday, 31 July 2026 14:04:01 CEST David Lee wrote:
Fixes 59741451b49c ("perf: Identify the 0->1 transition for event::mmap_count")

Bug found and triaged by OpenAI Security Research and validated by Trail of Bits.

Assisted-by Codex:gpt-5.6-sol gpt-5.5-cyber

1. weird text (advertisement) + newlines in the tags section which shouldn't be there
https://docs.kernel.org/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin
(and all these tag/format related sections below)

2. author didn't sign off the patch (see below)

3. odd unrelated Signed-off-by without any obvious connection to the patch

- I actually would guess that Kyle Zeng <[email protected]> is the author and David Lee removed its authorship (From: ) before sending the patch. But in its current form, David is claiming to be the author. And even when it is the case, David must still add the the non-Author SoB at the end.

Regards,
Sven