From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-188.mta1.migadu.com (out-188.mta1.migadu.com [95.215.58.188]) (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 9741C33D507 for ; Thu, 12 Mar 2026 02:24:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.188 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773282285; cv=none; b=Ok2bzUIJ1PeysEPgAfKeE4HGFPLz6MBz8mG+i2FviW+SFx2fM5dJSYx6fhVEloS7vDG2wUj7I7Onp3/mWMXYryK9tNBdgcEX9bcpPI0xRWouvTCwmQc8WYtJziGzNpAsfsSa5w9pdZcM1QEaDLpYcIvvJkeXRmUV+ITPtOYpS6U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773282285; c=relaxed/simple; bh=t/o8JZUco4a+9p05JAFPQThPlGv3WyinrLjprD+EYkA=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=bebBfeiZ46Gt5aCsPKZGzHF7piXn+8kdGKgZpDPnsERgEYlp0Y7xzXfzB0N82shHgBxRylGRCqbxgUcRHP+14c/zc6rjI0jL5hua5gTHYFbQBTb8SSJX+VuB5+MzoSx2NaSJrdYnuc2rGBouZ0YV5Mx6/aH6PzoBd++9jmARwB4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=WuIml8+b; arc=none smtp.client-ip=95.215.58.188 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="WuIml8+b" Message-ID: <931b490b-ab29-44fc-b888-8ac1ee8d8ccc@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1773282281; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=w+NS9REi3OjQ/Mu3hl26dakXZd5lzaswGeV0mI0VxH4=; b=WuIml8+bFNWIai4pwtX4tSQzikrGoTasWPFRug7mytOWFiHVJNt6mTJkktE1FTWXVKRaLT g1ZTGbjjaTi+mrujNQC9o7G5g6Q2iRFeWZg+YXNo/pvsk4EKezOY3WBmG3CzbloTpKjOfJ 6jEHTin93tow6aBkkOPbIY/3bFRGEoI= Date: Thu, 12 Mar 2026 10:24:24 +0800 Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH bpf-next v3 3/6] bpf: Disallow !kprobe_write_ctx progs tail-calling kprobe_write_ctx progs Content-Language: en-US To: Jiri Olsa Cc: bpf@vger.kernel.org, Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Eduard Zingerman , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Hao Luo , Shuah Khan , Feng Yang , Menglong Dong , Puranjay Mohan , =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= , Pu Lehui , linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, netdev@vger.kernel.org, kernel-patches-bot@fb.com References: <20260303150639.85007-1-leon.hwang@linux.dev> <20260303150639.85007-4-leon.hwang@linux.dev> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Leon Hwang In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT On 12/3/26 06:45, Jiri Olsa wrote: > On Tue, Mar 03, 2026 at 11:06:36PM +0800, Leon Hwang wrote: >> Uprobe programs that modify regs require different runtime assumptions >> than those that do not. Mixing !kprobe_write_ctx progs with >> kprobe_write_ctx progs via tail calls could break these assumptions. >> >> To address this, reject the combination of !kprobe_write_ctx progs with >> kprobe_write_ctx progs in bpf_map_owner_matches(), which prevents the >> tail callee from modifying regs unexpectedly. > > hi, > could you please give some example where this is actual problem? > I'd expect it's up to user (whoever installs the tailcall map) to > avoid such situations. > The self test in patch #6 can verify the problem, that kprobe_write_ctx=true progs can be abused to modify struct pt_regs via tail calls when tracing kernel functions using kprobe_write_ctx=false prog. Explain the problem by reusing the test code: int dummy_run; u64 data; struct { __uint(type, BPF_MAP_TYPE_PROG_ARRAY); __uint(max_entries, 1); __uint(key_size, sizeof(__u32)); __uint(value_size, sizeof(__u32)); } prog_array_dummy SEC(".maps"); SEC("?kprobe") int dummy_kprobe(void *ctx) { dummy_run++; bpf_tail_call_static(ctx, &prog_array_dummy, 0); return 0; } SEC("?kprobe") int kprobe(struct pt_regs *regs) { data = regs->di = 0; return 0; } The "kprobe" prog will be added to "prog_array_dummy" map. In user space, the "dummy_kprobe" prog will attach to kernel function "bpf_entry_test1". Actually, without this patch, when "bpf_fentry_test1" runs, the arg "a" will be updated as 0. Thus, bpf_prog_test_run_tracing() returns -EFAULT instead of 0. bpf_prog_test_run_tracing() |-->bpf_fentry_test1() |-->dummy_kprobe() |-->kprobe() /* via tail call */ |-->regs->di = 0; return 1; /* instead of 2 */ return -EFAULT; Yep, the commit log is not clear to describe this abuse problem. Will update it. Thanks, Leon