From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7CE3D3F075D for ; Thu, 6 Aug 2026 08:25:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786004737; cv=none; b=luoqwHpvyvHEtdO42tU3ghZgSyMPA0xwrh6XdD5Vzddqe30nwhsZOwFqQj3qjCuc73ObG9sIzkKdMjrbnEBwNN7Awp79ORt09vwh/mY3SptFDlZ9DXfhaJ1sQ+OkRpsBGMVgV7k0S1qlzAW/HxfcL/mw53UKO+maGGdZDzY64w0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786004737; c=relaxed/simple; bh=u35Fy/c9miFYfgIAMw9Zs68VFVkBNddOXa7Gm6zG6Qs=; h=From:Date:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=rwOxPZt5FmXNQ9hK9W6g+zanMhFW3AeTfKWiJkvZ2K0xO4NcMjzJ7mDis4Z00fSQNZwG69rZNn1xw94r8xDND4OJbQ4/SaHmrsrFbYpSvLG749nKj6igx1gi0ffkQpnfvEsWf1DJy0BGjFN7US1YDf+tBm26PYXJMIRXWzh2b58= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=A/SgNqn5; arc=none smtp.client-ip=209.85.128.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="A/SgNqn5" Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-495590dde14so20638665e9.0 for ; Thu, 06 Aug 2026 01:25:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786004727; x=1786609527; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:date:from:from:to:cc:subject :date:message-id:reply-to:content-type; bh=mvEGOYhp2CQZEcmymy9RcBUGgQ1zyWQcWI1QHnYNDi4=; b=A/SgNqn5MrMnrzwkQmrGmIqBHX6pOS5ZTHVuTDX7cSam+mSSrFw9ftKQ/GeoLsjvw4 kKUjwh+jOqnYlUOQaVmGQsA2SmCOZtzCn2wyR//zp3Axb+/sbYTQMfR2tmWLW5VoruHh bhQVuIDur72gPuwR0aL1r0AY8AfvQnhKYxKkX0aev+kvD7vtqzGDTIFJcKAzWKMLJU+1 CuNUCFqr+Do50uQSlD0QkgUkjhA0ueMUvQVCQ6p3+WZSiLN4CR+Dx75N6HNly31QQDNU oWTTA1waAMAOUVCCCHZQEqXUMc45pWHOXvo+yb4dBIlAw4QDP/QZwcQMCVkshgXYsGlv P/bA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786004727; x=1786609527; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=mvEGOYhp2CQZEcmymy9RcBUGgQ1zyWQcWI1QHnYNDi4=; b=X7JNTuetsHdrvZ1NQwI3+rNus87dZF8w/zsmHv0ao3/spEL3lfNmwcoAKiR/A8+CXf ec3RtyNg/eyNI6jiGo40/rpa5FNdDx/9rGysk+jfxVA0JeGaVPjH+5SEuKwFg34x6iI9 aNKveMF+ebX9IFmtILRmWTvpqIFw/a3m0CW3t+wCJFJk/GPyYcSHgNrRl3uPZiRxJWYk K99OjI28X1tuPbnGmmEmaSo/46exqu297R1+Rz/WatAY0hIjfCr+ajnQLMdyIn87s3jX 0uOuUKfQ55GLfRw2qNHzZL0mbhvj2qXNaPp8Dj9kfyzs9fauVG2Qi+y7Zv367spGu8H6 Cn1w== X-Forwarded-Encrypted: i=1; AHgh+RrDcwoEkSO+LuSva9j3zSjNNMWrZxx0lLHq33qPZHkVPMNS18RIAHdBJ4iJA6FZJ3D6VsTjqjOrp74NUWE=@vger.kernel.org X-Gm-Message-State: AOJu0YybP52h9iTP19HP7T/6h21oFQ6u8C7g6uTf33kVdhLWGkV8enbF Nwx6F9hlAZ75Edcb6O/II9yvErGEEKxgPEM1/qsQzDzoEcm1+hoGrRqi X-Gm-Gg: AR+sD12ESJMBnUuYsgntqBf7A2omFGylw+9Pr366gs7OF2HZ8W8nowEAX+bc/OSFLmA 1dbv9qLtkGjXwKfUgVwHNKsW+9bylZQD/vATfzdFXFs/HzRQbHgmTi9dHNsXas6BR7EJh0fdIkZ xBhTpcRi9Lixp2aF+losBtDjdP/O3bQ1GbTFXWyjXQzGtVrknoYhPQwJx4r+QQholnQqDFKEL68 WFFNp/bisP6ZXFShEn8iZ7R0hwuja/C2oNDwVxcuR2UNth1Qh4wSYs0THOEce+zL38Cmepv6hmZ it25OvQ3r0oIZoh8Yng3Z/E0/Tm5eLMrVAtIThb8BxeYaLfn+zBo2rXEonL1r92Gb9MEt6M4iOY WEjF+XFXAzbsp6oB1I5HwbnZxFnK42JH/F7T3ZQWIgoqt/Yi37xEOqbW3kZOM9+vlD7zyfO8GVk XGuqJkjzDRC29FF8u7ZpQxIuwNw8qyS9OlSffHXxHJ9w98Q0PrFs1nlBgmH9dRxkXAq8d1gxg= X-Received: by 2002:a05:600c:a45:b0:495:6478:2dbc with SMTP id 5b1f17b1804b1-4994e73cc5cmr165920225e9.6.1786004727128; Thu, 06 Aug 2026 01:25:27 -0700 (PDT) Received: from krava ([176.74.159.170]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4995421934asm45858475e9.5.2026.08.06.01.25.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Aug 2026 01:25:26 -0700 (PDT) From: Jiri Olsa X-Google-Original-From: Jiri Olsa Date: Thu, 6 Aug 2026 10:25:24 +0200 To: Hui Zhu Cc: Alexei Starovoitov , Daniel Borkmann , John Fastabend , Andrii Nakryiko , Eduard Zingerman , Kumar Kartikeya Dwivedi , Martin KaFai Lau , Song Liu , Yonghong Song , Emil Tsalapatis , Ihor Solodrai , KP Singh , Matt Bobrowski , Steven Rostedt , Masami Hiramatsu , Mathieu Desnoyers , bpf@vger.kernel.org, linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, Hui Zhu Subject: Re: [PATCH bpf-next v2 0/3] bpf: Fix UAF in bpf_trampoline_multi_attach/detach on update failure Message-ID: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Wed, Aug 05, 2026 at 12:04:05PM +0800, Hui Zhu wrote: > From: Hui Zhu > > This series fixes several use-after-free issues in the BPF trampoline > multi-attach/detach error paths, where ftrace direct-call updates can > fail and leave ftrace pointing at freed memory. hi, I need to stare at it bit more, but tbh I'm not sure the benefit of preventing hypothetical crash is worth the extra complexity on the detach side IIUC we can't reproduce this error without instrumenting the code, right? jirka > > Patch 1 addresses two UAF scenarios in bpf_trampoline_multi_detach(): > the single-point unlink failure path (old_image == cur_image) and the > batch ftrace update failure path. A new pinned_prog field in struct > bpf_tramp_image keeps the bpf_prog alive while ftrace may still > reference its image. bpf_trampoline_multi_detach() is made to return > void, since callers cannot usefully react to failures, and > bpf_trampoline_put() is taught to leak the trampoline when cur_image > was left behind by a rollback, so ftrace keeps a valid target. > > Patch 2 fixes a similar UAF in bpf_trampoline_multi_attach() rollback: > when the register-path undo fails, ftrace still calls into cur_image, > so the prog is pinned on cur_image instead of being rolled back. > > Patch 3 fixes the common __bpf_trampoline_unlink_prog() path, covering > both multi (bpf_trampoline_multi_detach) and non-multi > (bpf_tracing_link_release, bpf_shim_tramp_link_release) callers. > > Hui Zhu (3): > bpf: Fix UAF in bpf_trampoline_multi_detach on update failure > bpf: Fix prog UAF in bpf_trampoline_multi_attach() register-path > rollback > bpf: Fix prog UAF in __bpf_trampoline_unlink_prog() on update failure > > include/linux/bpf.h | 20 +++-- > kernel/bpf/trampoline.c | 183 +++++++++++++++++++++++++++++++++++---- > kernel/trace/bpf_trace.c | 2 +- > 3 files changed, 183 insertions(+), 22 deletions(-) > > Changelog: > v2: > Folded v1's two detach patches into patch 1. > According to the comments of Jiri Olsa, Pin the prog (pinned_prog) on > cur_image so it stays alive while ftrace may still call into it. > Make bpf_trampoline_multi_detach() return void. > Fix the same UAF in standard (non-multi) trampolines. > According to the comments of sashiko, Fix the prog UAF in > bpf_trampoline_multi_attach() rollback. > Leak the trampoline in bpf_trampoline_put() when cur_image is left > by a rollback. > > -- > 2.53.0 >