From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f48.google.com (mail-wr1-f48.google.com [209.85.221.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 AC1BF4562A6 for ; Fri, 7 Aug 2026 08:19:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786090783; cv=none; b=Ova1YyvYvP6/EMT652mPh55eQbYrlifDMd4B9DRtXqK/hqiba6f6JomscYZzr+0FvtjsGEUR1TVFkQPkRWY0FX9nq+F/e+0ywnSuNa6jv468cx+Nh3oEtBiSYNbSY79cjXOhxjXLn0C/XXaZiwv2l77A7gaqxyT5FS5VerCRfXQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786090783; c=relaxed/simple; bh=8lyBm9Wm93qDz42hxXXkdlccFQmsPzGQYDQhxrJxKW8=; h=From:Date:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=lTfUvHsAW1Mtk78XM4nePAJOfYbRH9Sd9dK7oyKw8HmtJ7mkuiK10DFwsxE9+tpXTB1pkIWvfRXMGfdUqhZ+D75jZOEwvm+bCitgattambv3ich8ii/3/Ca2h8Bh2u0OH18WIAuwy+UVUXoQ5bta91JxYWPCU3TjR9iKZSPK4YE= 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=C4Q6zPW0; arc=none smtp.client-ip=209.85.221.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="C4Q6zPW0" Received: by mail-wr1-f48.google.com with SMTP id ffacd0b85a97d-47c2b362ee2so2427041f8f.1 for ; Fri, 07 Aug 2026 01:19:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786090780; x=1786695580; 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=qieJb84NY/DGIyJFPREzT33jCTD11yTCdeI153UvP3Y=; b=C4Q6zPW0imL8i+4ZlJv8dhtubAV51gfBrV2vd706K2DAbnOsomN0GtqGFA4s/FceEw sHlSirW4x+NQfKSx0mZEL/yd73PSEQNRVrwF9vUZTECVdrryZNkK8q8KVbQai6SWE2/+ YwMU+vFWdhnEjQagl5OitKNjq7qyOPX2wJhg3aK1TT65cc0BN1BDKsmlSgMWXZtTpVH/ HUmS++JlBE/iYeGSprKPHGrkOsLHx/TjRwYPGnmm8aCI8d0W/Dj+mb8loWvzhQ5PLUa0 ZW33++s3IVnxYW28T9nEYgXIB1sYl7cdG6wutO2pUpsgalH0XapHR68jL3lasTDHzzTB Lr2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786090780; x=1786695580; 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=qieJb84NY/DGIyJFPREzT33jCTD11yTCdeI153UvP3Y=; b=FFQVLyeRHwceGcKTj8PwwTOi7R2dBCNJUUezKzi1MSVh1sW9rFZ1wtaKvvF0X+NZV0 KGfxj9rnAHUlIIHalH+MDShcmq8qJGw0LEadU50y/B0nxfJanbIXtEjU21CyqMi7UCuN DiMefGx1JJmr3SIRQnr1WhP0xKmfnm9n2SCdIcXHic80TILIIgeDwF7fX6hoPCHTnv/v 0k5ENysEmBRhIR4yzN9KGx82AfaNQDWQ7PNNj6ASa+zL88NQJTiRXYIRhJAr3p36GNE+ dsITW2BTQMprQ9qnWZ76y6o+Qjr9o9LhGTKANJFhRSzf7r0YNTLrEHbDd521LqB9DAJN 3m2Q== X-Forwarded-Encrypted: i=1; AHgh+Ro7SDyugYXRGYhXGDpotCbNQu0jZTePCGek8lVeUHFN9yGK7icOoyVNGtrHpM/dkP/n5+8XAj81VA8KdAM=@vger.kernel.org X-Gm-Message-State: AOJu0YyWPaziwrFuML5953YsJcCk8L2eEC7DwYa6mlbXmeC4EZ4LSE+w f6wAWCjVe3qjr54LbXMt+MKtez4sNTcLQPvZwAaZUNBcYjwMoUHQxBJz X-Gm-Gg: AR+sD13DiSSCA2/UOoRzqLLreY5Q+iMPstSi2Ha09IF15MAbQ32WohXAXxC0lEEp3BQ REb31DgDy3CCy4W2z7n3MlMzbe2QMGuBc5Jo4hvwNVSHBWuGmMpt/d8RDvSXmlS92+xTbJ9iAkS pX3M9o4TVJxhcvOJZwdn9jDP7mX4EMZkyRLvB5/G7XqmNbL6MAqaWkjrTb+PcXPKBxqyCEy9Omn qQO5VZsTMjG3R/sHbWQeUp2Ws1ytUYhQxfwb81hP1uko17GClVLvjOaPyi7tyta2wXNeCG6sNmE UZbBjPxTHAsRjnaCuSlBYNBmeAGkez9bdP8UzhH0hvfc3ZRMMz2eaesSPaP+niwmEotWYcmPdm9 mBBE9660ineYrAEbKZ8nQoJEdpBzdtisHkiUCtFDeIyazP4+LIYHNob/7iLQ6fUdWPCJQcpTalM jc1FeRUL+lsaZ4EFWNA382fsIByUB62Q0cUw== X-Received: by 2002:adf:e001:0:20b0:47f:e721:1f77 with SMTP id ffacd0b85a97d-47fec51f260mr26165338f8f.13.1786090779619; Fri, 07 Aug 2026 01:19:39 -0700 (PDT) Received: from krava ([2a02:8308:a00c:e200::cded]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48002150952sm3057648f8f.15.2026.08.07.01.19.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 07 Aug 2026 01:19:39 -0700 (PDT) From: Jiri Olsa X-Google-Original-From: Jiri Olsa Date: Fri, 7 Aug 2026 10:19:37 +0200 To: Hui Zhu Cc: Jiri Olsa , 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: <4a6ee31b46b732eaad76b955d95c8cc261941894@linux.dev> 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: <4a6ee31b46b732eaad76b955d95c8cc261941894@linux.dev> On Fri, Aug 07, 2026 at 02:00:11AM +0000, Hui Zhu wrote: > > > > 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 > > Hi Jiri, > > You're right. I went through the failure paths and the realistic > triggers basically don't exist for a normal user: > > The allocations are all GFP_KERNEL (reclaim + OOM handle them), > and bpf_jit_charge_modmem() lets CAP_BPF callers exceed the JIT > limit, so ENOMEM doesn't get there. > -E2BIG is attach-time, before cur_image is set, so no UAF. > SHARE_IPMODIFY -EAGAIN needs livepatch on the same function and > is retried in bpf_trampoline_update(); the multi path where it > could escape needs a second failure on the undo del, which doesn't > do ipmodify negotiation, so it doesn't reach the UAF either. > The rest is bugs or not user-driven. > > So this is fault-injection territory, and I won't claim it's > a customer bug. > > I'd like to drop patches 2 and 3 and the prog-side machinery > (pinned_prog + rollback + the trampoline leak). > And keep only the one-line image-side fix in patch 1: only free > old_image when it differs from cur_image. right, that one looks good > It's obviously correct: if cur_image == old_image, ftrace is still > calling into it, so freeing it is wrong. And it costs almost nothing. > > Would you prefer I proceed with just this single patch, > or drop the entire series instead? also we can change bpf_trampoline_multi_detach to return void and drop the WARN_ON_ONCE on that call thanks, jirka