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 88D981F8697; Tue, 17 Dec 2024 17:17:27 +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=1734455847; cv=none; b=F+ne3ghdUJBs6JnMD9pRmwXyrGQ2w6cWcSUiLKDrY/7lgFTOTn8IoY/1z6zYLcYBf3CwnCvqQDZWm55VoUDvw6JQm04Tr5qSJ42RtOCS9S41aoJvMWV89dRdx+3gSQysdxOMUmI//bBAFu9QJAWgAUnD7Ni6NKl/O1zGY7I5Smg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734455847; c=relaxed/simple; bh=usTuaXtWzKR0I+Ph6tTOD512XnpE7+Tz6dVtwAtat68=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=H3qY1/LWL0/B6ioSjmBw0Ra0F0c0n7EEPrM8ecNVGjzMaP5HN49Cl5KdaxIcvz1q6BrLwvyb6lObdf/NvngKdSdz84pLHUtaae3hmWf/nfedIOW6uGk5U2UKinSObueOzbp56eqdsw7gKgTMnwpusU4EVH/T9cN5j/vM7XqojI0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=boW3j7zv; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="boW3j7zv" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0CE01C4CEDF; Tue, 17 Dec 2024 17:17:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1734455847; bh=usTuaXtWzKR0I+Ph6tTOD512XnpE7+Tz6dVtwAtat68=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=boW3j7zvoDWASpv5fHC+/oRAzsGdtL+4iGdHGYIJfIjHsE90XeLTeZaYb+YUsDHcv OmVx/fd86Fx7IFiN6ghlHiz7Ps9RGR58QR0IK1KDC3Xp6x/8tqh7yKKvfUjOyV/Y2X 3chEPrF7bwyg76EJ+qg8GHiND5CHXfemeAj0pmlw= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, syzbot+2e0d2840414ce817aaac@syzkaller.appspotmail.com, Jiri Olsa , Andrii Nakryiko Subject: [PATCH 6.1 22/76] bpf,perf: Fix invalid prog_array access in perf_event_detach_bpf_prog Date: Tue, 17 Dec 2024 18:07:02 +0100 Message-ID: <20241217170527.177279973@linuxfoundation.org> X-Mailer: git-send-email 2.47.1 In-Reply-To: <20241217170526.232803729@linuxfoundation.org> References: <20241217170526.232803729@linuxfoundation.org> User-Agent: quilt/0.67 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 6.1-stable review patch. If anyone has any objections, please let me know. ------------------ From: Jiri Olsa commit 978c4486cca5c7b9253d3ab98a88c8e769cb9bbd upstream. Syzbot reported [1] crash that happens for following tracing scenario: - create tracepoint perf event with attr.inherit=1, attach it to the process and set bpf program to it - attached process forks -> chid creates inherited event the new child event shares the parent's bpf program and tp_event (hence prog_array) which is global for tracepoint - exit both process and its child -> release both events - first perf_event_detach_bpf_prog call will release tp_event->prog_array and second perf_event_detach_bpf_prog will crash, because tp_event->prog_array is NULL The fix makes sure the perf_event_detach_bpf_prog checks prog_array is valid before it tries to remove the bpf program from it. [1] https://lore.kernel.org/bpf/Z1MR6dCIKajNS6nU@krava/T/#m91dbf0688221ec7a7fc95e896a7ef9ff93b0b8ad Fixes: 0ee288e69d03 ("bpf,perf: Fix perf_event_detach_bpf_prog error handling") Reported-by: syzbot+2e0d2840414ce817aaac@syzkaller.appspotmail.com Signed-off-by: Jiri Olsa Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20241208142507.1207698-1-jolsa@kernel.org Signed-off-by: Greg Kroah-Hartman --- kernel/trace/bpf_trace.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/kernel/trace/bpf_trace.c +++ b/kernel/trace/bpf_trace.c @@ -2180,6 +2180,9 @@ void perf_event_detach_bpf_prog(struct p goto unlock; old_array = bpf_event_rcu_dereference(event->tp_event->prog_array); + if (!old_array) + goto put; + ret = bpf_prog_array_copy(old_array, event->prog, NULL, 0, &new_array); if (ret < 0) { bpf_prog_array_delete_safe(old_array, event->prog); @@ -2188,6 +2191,7 @@ void perf_event_detach_bpf_prog(struct p bpf_prog_array_free_sleepable(old_array); } +put: /* * It could be that the bpf_prog is not sleepable (and will be freed * via normal RCU), but is called from a point that supports sleepable