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 4747D2248AF; Wed, 28 May 2025 21:56:09 +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=1748469370; cv=none; b=XzmgQJ9nTaf+o9lEPP1UVty5BJ97fn0N9OMUxbq9by4js0zWSaxs1ZDGyjXq+xgeYwy0TBnqwLvoX+iAwJKMIbjcUOKxmP4aok7XQnAdO+BB7xr9c8N1e/JhfScGcmR4RD803CMIMva/P4XiNKCA3OzfghaUPc+r8GtXQxuVLFY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1748469370; c=relaxed/simple; bh=OLr+lHLF1b6leX+yACQ6obVgGCNqcRl/H9Y7AcITMvA=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=YHknn+vq5J+EZa698sdeCuiM3kF8OuBrnxJYDIXyg5PY7SgDAJHSEvu2mM/30nkF3seLMEcYxh7o+1haL5P93o727nD7w9mbMmbqCI4lM6zebJWtOClRel+Vo3GdEYGb2sNuncwQSdI9YVlXpvxykWpTrqAB6yD7qz2B/qThCfg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=nC0sWeVD; 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="nC0sWeVD" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A0C80C4CEE3; Wed, 28 May 2025 21:56:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1748469369; bh=OLr+lHLF1b6leX+yACQ6obVgGCNqcRl/H9Y7AcITMvA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=nC0sWeVD0fHisq/7MJjoFr41TR61GiXvqn/w4o/GZFlSSjiOdbQxlvMADKoGUz57k J0Sd2546EjRjmnRdi7/EABCcrQwFs5pdAdxxrCbb7sWCdYlnLysCNVfPwWKDe8ckO7 bW7SerFhUEXsbP6gm7A5aUKWjjpEGzO//S2jBa7xE/cAHbfjbhELznJ5F0rM91GrMl 2q9bL5DHCKCpxeqpNtrYjVxsBt8Nfv9dw3eYaZE+1b6a04fJ3X9Ne964z3uoFs1wOM FGuZFOMixj31o7WxZTux45SM1k5V1TCq3lkkYGUAyw5d9FLFubRNnuIhLAmVJVb2Vu wN/PxudwbqFsQ== 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.15 8/9] perf: Ensure bpf_perf_link path is properly serialized Date: Wed, 28 May 2025 17:55:58 -0400 Message-Id: <20250528215559.1983214-8-sashal@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20250528215559.1983214-1-sashal@kernel.org> References: <20250528215559.1983214-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 6.15 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 95e703891b24f..eaa9588eb968d 100644 --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -6239,6 +6239,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) { @@ -6301,7 +6304,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; @@ -11069,8 +11072,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; @@ -11108,6 +11112,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 (!event->prog) @@ -11130,7 +11148,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