From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C5A5B40D57F for ; Mon, 29 Jun 2026 19:15:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.168.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782760547; cv=none; b=kjSpTAUO/UmHoGIXzVftu4mG4sJlf1jlUR19JmCu1nYmLa89FGjV0VEfvUSL1n1DWFCiGHSm0PbzJNiB8HHQGVL0prMVyLhxZwKMxQCx9iZ9Bfbili9hNHoqQgkNpoo7yqil0CsO+w1CLRGxfg8qnPdjKgLD1cyVCfOCwQdydMs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782760547; c=relaxed/simple; bh=lJ5zKooiKzbg8+escUbbnQhwFlA5qAdIRzAYA7f4WWA=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=B9orD1Ot5KHQtPjsZ/gVKTo8pRhvvrkzgdq74pbLVTKpQmUYVpWGubnLBdBP6qk+8WXEssAerYp2TzohiumdOXOJklmZgVVyyFCTFyfA6fDAy/4450jkGiyhWXUNeagaL73+Lw6+hpfKzz3Ojv8EQi3AMbdX3yNJKb5cd0cyiac= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com; spf=pass smtp.mailfrom=oss.qualcomm.com; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b=nSPzG7M2; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=dnLHoONW; arc=none smtp.client-ip=205.220.168.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b="nSPzG7M2"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="dnLHoONW" Received: from pps.filterd (m0279863.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 65TGKZXQ3447792 for ; Mon, 29 Jun 2026 19:15:45 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= 8I++PrbSy0ZEcGYwTL0DodAEWjo7ZIRg4CczMtI/2/0=; b=nSPzG7M2goE4mc00 nfGAz8JZuftvoOCPPTGON8zmNL8i2OJXrQd6+7DSaOuEWTTKi0admbMXwxnECo1q YovPb2Q0DmzK5jXRdvf8vHuET8aNfeQeWUCvTAMrCW3r1buQteUevfYpYAtOUI54 WDt5HOi/h/kTgxRy4J8IqiQLHu/VNzXDEoZ35mkgtV4WwE/BBjlivbn4/UtEwcHa hmuBGzqqNiG2CV5UWxwMqGftOOxyhphkVdXiJAeVx5P8Qp86/bZemMHE2hdEdKy9 2nKPZkCv3mTs4ZmBk1VGSreVIFaJHwx0z/cb6RdKphpnLoGvKry2MJyb3wlxQWHl 7bRmeA== Received: from mail-dy1-f199.google.com (mail-dy1-f199.google.com [74.125.82.199]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4f3npetqcx-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Mon, 29 Jun 2026 19:15:44 +0000 (GMT) Received: by mail-dy1-f199.google.com with SMTP id 5a478bee46e88-30b877ee493so5608806eec.1 for ; Mon, 29 Jun 2026 12:15:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1782760544; x=1783365344; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=8I++PrbSy0ZEcGYwTL0DodAEWjo7ZIRg4CczMtI/2/0=; b=dnLHoONWx3HnOmJSihnBYyOwSr8Ni6wuP9gWVqJKWMAOegVUAQqCCILEo4Yrjg/j14 9unwSF5GpJtWmYsMPvKCrzC1zADz5z6vzZ0BuDeyND7YHcuUBcf4/KxkXVA4K9vzZUgR pXCwzCRGogJT6keZIDCySRQXVEZ4aJaoxYblWoQL3g9hyPRblLnQ06rGh0gevqoNlVuU tZ/tajj5DOAzqvprfsArKaChuCc+12TS554I0aAu7TeoA3PN1eavL0efI/2niViLr5vo H8+Rz39rNQji+hydtFDqYyldC1Zy+dunWFIowL5gG4dEKAc3WWTo99WHUiS15HvfmC5S 7M3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782760544; x=1783365344; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=8I++PrbSy0ZEcGYwTL0DodAEWjo7ZIRg4CczMtI/2/0=; b=QSyE8u1wDqPGMSRGv0w6rYkiUL2DMu2pLyvLLGPU0dz+6r3sdUCfEH7J+7a/mW3T3r gUTCQp5MGwzmlj++r93vGtZeFWpIYWuFInNhvbeHRTSA0HAeI2rwhl6XO4T+86st4JN1 29AhlG0qaW+CXijGeVI+r7Fy8+95PxqcUzPFCXLOs91rMm1zUzZhc4Rz1ThBvBMOs1Z/ vBKUmUnhDXmEqNP8vJN/hbhahg1VE38nXLeLtiRDCa9j1uxsxFxmhid0NlLFJERzWGXr 0MwFUN37nD6IMbzB/9gliXjjluwN64dgtR1eF+CU2b5sL6ULt4rEycIpv2DqccSzviNf lUbw== X-Forwarded-Encrypted: i=1; AHgh+RqF7Rg03S8Ld/xAxxFXzdyisNvi8QK3sczefYz1DKJ6/gCgENVIM5iXZ2AfqGaNm0MxqM6V1csdPSu2Q4w=@vger.kernel.org X-Gm-Message-State: AOJu0YzxVWkdQ1LeSxMF4VwhPa7RG4BL0Rb63FiwM7QwqhCCp7+tpRlH twEVWBx0XLxA5pQjQr5pgZJvCV/eVr5GkxkY6iaNL0W9kw8P+i2E9FFRpmX2RSsjQkCl8wzWmPX 7KzWOrDoEJHAbW2+UVx8Uz1Pe2sJmOMBdlcHpl7IM3zeyvvD11KDXtUwW84cBCJBoIXQ= X-Gm-Gg: AfdE7cnMj5kRt3aNFHpOgZHErQ1EgJB0HhY4UUfUPWCM/7v7iYzsUU2pHvM4zDGbXk4 +4pqkO//ArZVXJOA2agp9QWF3SsQTry5Pswc1aYE3IVTS0FYMYLthafgezhA+UO0TCIHZ4YTnM5 OgFItNed1JZVCodQAN5sQwb322jgGp/73fSIDLGUyxxpsbKMUg3N3FuGMGt/N/zOBgc6yx9V767 gAO3zfyrtCLHo8VdKTcOOfOeCLLtbGhPU9MSx4ujtgyYlIk4bSwm7zP91oyO2CcGGCTlMK+hzph i2sWr6g8prtZFejdnnFSUtmOerTdLQNCkr9dWRfgLK0J6Z3ENUh176j79sVlLWjPfec01Xrz11O yFMsn1kwbvgfbKXts74bAB1o5mwJCz6RNUMBuc9AaJDPLJA== X-Received: by 2002:a05:7300:214f:b0:30c:ab96:7302 with SMTP id 5a478bee46e88-30ee1c8869bmr348311eec.18.1782760543857; Mon, 29 Jun 2026 12:15:43 -0700 (PDT) X-Received: by 2002:a05:7300:214f:b0:30c:ab96:7302 with SMTP id 5a478bee46e88-30ee1c8869bmr348277eec.18.1782760543193; Mon, 29 Jun 2026 12:15:43 -0700 (PDT) Received: from [192.168.1.7] ([122.177.244.195]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-30ee2f5ed29sm418697eec.1.2026.06.29.12.15.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 29 Jun 2026 12:15:42 -0700 (PDT) Message-ID: <608f1601-cef4-4c66-9d82-8d3827e8ac50@oss.qualcomm.com> Date: Tue, 30 Jun 2026 00:45:34 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] perf/core: Fix group leader use-after-free after sibling detach To: "Mi, Dapeng" , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , James Clark Cc: Peter Zijlstra , Ingo Molnar , linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org References: <20260626-fix-group-leader-uaf-v1-1-ac54652ca944@oss.qualcomm.com> <67f56151-3164-4922-a85b-e511b2c448e8@linux.intel.com> Content-Language: en-US From: Aditya Chillara In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNjI5MDE2MSBTYWx0ZWRfX5BD/bOGCdhGq A08DDNsmLGJohNrLF1APYlCT/wME6F2HZ4mRN+3t++1ZqWOKRgsBq0XKg5HC+OYFcYpvZIxleDD CxEa1APSH3dZ+EZ/hkuBUx+HwslyLedHWDOUUNZe/FaBF8r5/KIZGB1uK0f23qmGmRtWnT6Z9xP 4t+E/qwuDzlrhLRI6ttPvb6XpbH6uaN8W2ePNIxEIVaYIe+OvKW4w4MsUQwpeCdEPQdRiFyoPnA puxtj0FVuiFEEFTowjMVPMObFkCtCfy2tSZ3eh8Wma5nav3RKwvXoO15Evwq+bvHeE1Oqk3qNmF 0DoNdW/wv/CGHZQN4QjJ6/hh5sPsV45fEGh4WlgPh5vQLzwq7E8bZFs5gKFniUXg+sVCaGmxrcw GTqgWH+sUYzRKh4ukSEHkSkSGLnp83KivO9x4BvdkT+mfIvsBoaTjOBtBXKkgRsZ/6lOeUjdtlP gokEBh4rQ2+jMhF0xKw== X-Proofpoint-ORIG-GUID: RVU23C8mGvNVIlfATUFudBGDZQsJurjW X-Authority-Analysis: v=2.4 cv=T6q8ifKQ c=1 sm=1 tr=0 ts=6a42c460 cx=c_pps a=cFYjgdjTJScbgFmBucgdfQ==:117 a=cBpEFP3VsKMDvY265z5wtw==:17 a=IkcTkHD0fZMA:10 a=FelO9ux0wxsA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=yOCtJkima9RkubShWh1s:22 a=EUspDBNiAAAA:8 a=mKdH2X2G3I8vq56XIfkA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=scEy_gLbYbu1JhEsrz4S:22 X-Proofpoint-Spam-Info: AW1haW4tMjYwNjI5MDE2MSBTYWx0ZWRfX1w7zzkQZ+gZJ D1VmNgntbGzG7bJ+cD4a8ccwepBQBPenuG1CBr7VAZtW+sm0iyj82qFxBdcZIyLdkw1ZPAlk580 Cm4VHELozVhzolRZ8pGk87NCSkxUMf4= X-Proofpoint-GUID: RVU23C8mGvNVIlfATUFudBGDZQsJurjW X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.125,FMLib:17.12.100.49 definitions=2026-06-29_04,2026-06-26_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 priorityscore=1501 suspectscore=0 clxscore=1015 adultscore=0 lowpriorityscore=0 malwarescore=0 impostorscore=0 phishscore=0 bulkscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2606290161 On 6/29/2026 12:36 PM, Mi, Dapeng wrote: > > On 6/29/2026 12:00 PM, Aditya Chillara wrote: >> On 6/29/2026 8:28 AM, Mi, Dapeng wrote: >>> On 6/26/2026 5:54 PM, Aditya Chillara wrote: >>>> perf_group_detach() handles leader and sibling detach differently. When the >>>> group leader is detached, all siblings are promoted to singleton events and >>>> their group_leader pointer is reset to themselves. When a sibling is >>>> detached, it is removed from the leader's sibling_list, but its >>>> group_leader pointer is left pointing at the old leader. >>>> >>>> That is harmless when the sibling is being closed and freed immediately, as >>>> in the DETACH_DEAD path. It is not safe when the sibling is detached but >>>> kept alive, such as during CPU hotplug with DETACH_GROUP. In that case the >>>> sibling is removed from the context, while its file descriptor can still >>>> keep it alive. >>>> >>>> A typical failing sequence is: >>>> >>>> - A group contains leader L and sibling S. >>>> - CPU hot-unplug detaches S with DETACH_GROUP, removing it from >>>> L->sibling_list but leaving S->group_leader == L. >>>> - L is later closed and freed. >>>> - A PERF_IOC_FLAG_GROUP ioctl on S follows S->group_leader and >>>> dereferences the freed leader. >>>> >>>> This was reproduced by running the perf event fuzzer, CPU hotplug, and a >>>> stress workload concurrently: >>>> >>>> Unable to handle kernel paging request at virtual address 006b6b6b6b6b6cdb >>>> CPU: 2 PID: 12489 Comm: perf_fuzzer 6.18.7 PREEMPT >>>> pc : perf_ioctl+0x34c/0xc68 >>>> x20: ffffff89a3fa2c70 x8 : 6b6b6b6b6b6b6b6b >>>> Code: 943c4a0e 340047a0 f9404a94 f9411e88 (f940b908) >>>> Call trace: >>>> perf_ioctl+0x34c/0xc68 (P) >>>> __arm64_sys_ioctl+0xa0/0xf4 >>>> invoke_syscall+0x58/0xe4 >>>> el0_svc_common+0xa8/0xdc >>>> do_el0_svc+0x1c/0x28 >>>> el0_svc+0x40/0xc0 >>>> el0t_64_sync_handler+0x68/0xdc >>>> el0t_64_sync+0x1c4/0x1c8 >>>> >>>> The fault happened in perf_ioctl(), where perf_event_for_each() follows >>>> the stale group_leader pointer and perf_event_for_each_child() then >>>> dereferences the freed leader's context. >>>> >>>> Fix the use-after-free by promoting the detached sibling to a singleton. >>>> >>>> Fixes: 8a49542c0554 ("perf_events: Fix races in group composition") >>>> Assisted-by: PatchWise:gpt-5.5 >>>> Signed-off-by: Aditya Chillara >>>> --- >>>> kernel/events/core.c | 20 ++++++++++++++++++++ >>>> 1 file changed, 20 insertions(+) >>>> >>>> diff --git a/kernel/events/core.c b/kernel/events/core.c >>>> index 954c36e28101..dd9892040ab2 100644 >>>> --- a/kernel/events/core.c >>>> +++ b/kernel/events/core.c >>>> @@ -2605,6 +2605,26 @@ __perf_remove_from_context(struct perf_event *event, >>>> perf_child_detach(event); >>>> list_del_event(event, ctx); >>>> >>>> + if ((flags & DETACH_GROUP) && event->group_leader != event) { >>>> + /* >>>> + * list_del_event() needed the old group_leader to tell a real >>>> + * leader from a sibling. That's done now, so make the detached >>>> + * sibling self-contained. >>>> + */ >>>> + event->group_leader = event; >>>> + event->group_caps = event->event_caps; >>>> + >>>> + /* >>>> + * PERF_EV_CAP_SIBLING event requires being part of a group, so move >>>> + * the event to ERROR state if it is still alive. >>>> + */ >>>> + if ((event->event_caps & PERF_EV_CAP_SIBLING) && >>>> + event->state > PERF_EVENT_STATE_ERROR) >>>> + perf_event_set_state(event, PERF_EVENT_STATE_ERROR); >>>> + >>>> + perf_event__header_size(event); >>>> + } >>>> + >>> Why not move this part of fixing code into perf_group_detach()? It seems a >>> better place to fix the issue. Thanks. >> Because list_del_event() just above my change does: >> >> if (event->group_leader == event) >> del_event_from_groups(event, ctx); >> >> so resetting the group leader in perf_group_detach() would attempt removing sibling >> event->group_node from a group rb-tree it was never added to (only leader gets added >> in list_add_event()). > > Yeah, but I don't see why we can't do same thing for the sibling event > detaching in perf_group_detach(). Just like the group leader detaching, > each sibling event would be re-added into ctx groups by calling > add_event_to_groups(). Suppose we can do same thing for the sibling event > detaching, call add_event_to_groups() to add the standalone event into ctx > groups, right? Yup, that's a cleaner fix, sent v2! Thank you, Aditya > > >         if (sibling->attach_state & PERF_ATTACH_CONTEXT) { >             add_event_to_groups(sibling, event->ctx); > >             if (sibling->state == PERF_EVENT_STATE_ACTIVE) >                 list_add_tail(&sibling->active_list, get_event_list(sibling)); >         } > > >>> >>>> if (!pmu_ctx->nr_events) { >>>> pmu_ctx->rotate_necessary = 0; >>>> >>>> >>>> --- >>>> base-commit: ab9de95c9cf952332ab79453b4b5d1bfca8e514f >>>> change-id: 20260626-fix-group-leader-uaf-c46960e525e0 >>>> >>>> Best regards, >>>> -- >>>> Aditya Chillara >>>> >>>> >>