From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 457D0221DAB; Wed, 28 May 2025 21:56:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1748469381; cv=none; b=lI8bVOOsQSwy78/+tBBdgme10IMejbVINlxNKRL+d+SrKLwMriOpNzoB+5l1i7/ClNfU7+An5inF0TBWY9bnE5K+z3vfB/79RduGJp/wWp3si/UHe06Jo76Hn0PSqN/7It8G1MWX7IHd5heUAutADrwu90pbLDFobiSl55CAVcA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1748469381; c=relaxed/simple; bh=vJwXZiw5MglL9doiTD30c3wKbGdslGUG52zGdsyfu74=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=DBDkSr5bucqHb/MaPSKhgocc/YaTxZb+HZXB48eawb5rNuLj/XU+JW3/mfxoudmtM8GJqoNTmfHuubkkTE9BsMlKa1crYMYv/3wY3dG0pnwFmKyQwAqoMxs28VUxM3QP5c3qPlkqsEmbT36VjaywFJsxFwYZuntTYGFw0W3V2z4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=vAaW0xzy; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="vAaW0xzy" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 911C3C4CEE7; Wed, 28 May 2025 21:56:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1748469380; bh=vJwXZiw5MglL9doiTD30c3wKbGdslGUG52zGdsyfu74=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=vAaW0xzyPFT50ed9zOGo3bRAbsg4iJ4dwVuYDn8mnUTr8cFr/Buxex6gzOPDCVt4p zgSllTzTT/w0FLXhqnNHxbwR22vCgpxgM5jahvKKUhe4pbpDFGjbRWBg4lL8a31q+b Mey2ZBUfyRbkkonRJgdVP4w6vZY2tI35nJp/pKiSTm7pUyytMCIN/p2pNGoW6ZIdUh jahvhKsacWBi6xDFylYbmGjMFWcKy4bsZ3PUZTVQ19pc1Cd0VToUkPPsL0jPDMyZbg 0am+lH/iCxLNzWQFu5tOzoJjKOU+cm6nFz/lNlR57lq73hfdk40WLwP0A5An3wlS1x JfplUq7XLaJyw== From: Sasha Levin To: patches@lists.linux.dev, stable@vger.kernel.org Cc: Peter Zijlstra , Ravi Bangoria , Sasha Levin , mingo@redhat.com, acme@kernel.org, ast@kernel.org, daniel@iogearbox.net, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, bpf@vger.kernel.org Subject: [PATCH AUTOSEL 6.14 7/8] perf: Ensure bpf_perf_link path is properly serialized Date: Wed, 28 May 2025 17:56:10 -0400 Message-Id: <20250528215611.1983429-7-sashal@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20250528215611.1983429-1-sashal@kernel.org> References: <20250528215611.1983429-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 6.14.8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Peter Zijlstra [ Upstream commit 7ed9138a72829d2035ecbd8dbd35b1bc3c137c40 ] Ravi reported that the bpf_perf_link_attach() usage of perf_event_set_bpf_prog() is not serialized by ctx->mutex, unlike the PERF_EVENT_IOC_SET_BPF case. Reported-by: Ravi Bangoria Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Ravi Bangoria Link: https://lkml.kernel.org/r/20250307193305.486326750@infradead.org Signed-off-by: Sasha Levin --- Based on my analysis of the commit and the kernel tree context, here is my evaluation: **YES** This commit should be backported to stable kernel trees. Here's my detailed analysis: ## Bug Analysis The commit fixes a **race condition and security vulnerability** in the BPF perf event attachment path. Specifically: 1. **Race Condition**: The `bpf_perf_link_attach()` function calls `perf_event_set_bpf_prog()` without holding the `ctx->mutex`, while the equivalent ioctl path (`PERF_EVENT_IOC_SET_BPF`) properly acquires this mutex before calling the same function. 2. **Inconsistent Locking**: The fix shows two different code paths accessing the same critical section with different locking semantics: - **ioctl path** (line 2309): Acquires `ctx->mutex` via `_perf_ioctl()` → `__perf_event_set_bpf_prog()` - **bpf_perf_link_attach path**: Called `perf_event_set_bpf_prog()` directly without mutex protection ## Code Changes Analysis The fix introduces proper serialization by: 1. **Creating `__perf_event_set_bpf_prog()`**: An internal version that doesn't acquire locks 2. **Modifying `perf_event_set_bpf_prog()`**: Now acquires `ctx->mutex` before calling the internal version 3. **Updating ioctl path**: Uses the internal version since it already holds the mutex ## Why This Should Be Backported 1. **Security Impact**: Race conditions in BPF attachment can lead to use-after-free or other memory corruption issues that could be exploited 2. **Bug Fix Nature**: This is clearly a bug fix that addresses inconsistent locking semantics rather than adding new features 3. **Minimal Risk**: The change is small, contained, and follows existing patterns - it simply ensures consistent locking across both code paths 4. **Critical Subsystem**: This affects the BPF subsystem and perf events, both critical kernel components where race conditions can have serious security implications 5. **Similar Historical Precedent**: Looking at the reference commits, commit #5 with "Backport Status: YES" was backported for fixing a similar type validation issue in BPF perf events, showing that BPF perf-related fixes are appropriate for stable trees The commit addresses the exact type of concurrency bug that stable trees are designed to fix - it's a clear bugfix with minimal regression risk that addresses a potential security vulnerability in a critical kernel subsystem. kernel/events/core.c | 34 ++++++++++++++++++++++++++++++---- 1 file changed, 30 insertions(+), 4 deletions(-) diff --git a/kernel/events/core.c b/kernel/events/core.c index 93ce810384c92..bdbd119b6d06a 100644 --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -6015,6 +6015,9 @@ static int perf_event_set_output(struct perf_event *event, static int perf_event_set_filter(struct perf_event *event, void __user *arg); static int perf_copy_attr(struct perf_event_attr __user *uattr, struct perf_event_attr *attr); +static int __perf_event_set_bpf_prog(struct perf_event *event, + struct bpf_prog *prog, + u64 bpf_cookie); static long _perf_ioctl(struct perf_event *event, unsigned int cmd, unsigned long arg) { @@ -6077,7 +6080,7 @@ static long _perf_ioctl(struct perf_event *event, unsigned int cmd, unsigned lon if (IS_ERR(prog)) return PTR_ERR(prog); - err = perf_event_set_bpf_prog(event, prog, 0); + err = __perf_event_set_bpf_prog(event, prog, 0); if (err) { bpf_prog_put(prog); return err; @@ -10799,8 +10802,9 @@ static inline bool perf_event_is_tracing(struct perf_event *event) return false; } -int perf_event_set_bpf_prog(struct perf_event *event, struct bpf_prog *prog, - u64 bpf_cookie) +static int __perf_event_set_bpf_prog(struct perf_event *event, + struct bpf_prog *prog, + u64 bpf_cookie) { bool is_kprobe, is_uprobe, is_tracepoint, is_syscall_tp; @@ -10838,6 +10842,20 @@ int perf_event_set_bpf_prog(struct perf_event *event, struct bpf_prog *prog, return perf_event_attach_bpf_prog(event, prog, bpf_cookie); } +int perf_event_set_bpf_prog(struct perf_event *event, + struct bpf_prog *prog, + u64 bpf_cookie) +{ + struct perf_event_context *ctx; + int ret; + + ctx = perf_event_ctx_lock(event); + ret = __perf_event_set_bpf_prog(event, prog, bpf_cookie); + perf_event_ctx_unlock(event, ctx); + + return ret; +} + void perf_event_free_bpf_prog(struct perf_event *event) { if (!perf_event_is_tracing(event)) { @@ -10857,7 +10875,15 @@ static void perf_event_free_filter(struct perf_event *event) { } -int perf_event_set_bpf_prog(struct perf_event *event, struct bpf_prog *prog, +static int __perf_event_set_bpf_prog(struct perf_event *event, + struct bpf_prog *prog, + u64 bpf_cookie) +{ + return -ENOENT; +} + +int perf_event_set_bpf_prog(struct perf_event *event, + struct bpf_prog *prog, u64 bpf_cookie) { return -ENOENT; -- 2.39.5