public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Jiri Olsa <olsajiri@gmail.com>
To: Leon Hwang <leon.hwang@linux.dev>
Cc: bpf@vger.kernel.org, "Alexei Starovoitov" <ast@kernel.org>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	"Andrii Nakryiko" <andrii@kernel.org>,
	"Martin KaFai Lau" <martin.lau@linux.dev>,
	"Eduard Zingerman" <eddyz87@gmail.com>,
	"Song Liu" <song@kernel.org>,
	"Yonghong Song" <yonghong.song@linux.dev>,
	"John Fastabend" <john.fastabend@gmail.com>,
	"KP Singh" <kpsingh@kernel.org>,
	"Stanislav Fomichev" <sdf@fomichev.me>,
	"Hao Luo" <haoluo@google.com>, "Shuah Khan" <shuah@kernel.org>,
	"Feng Yang" <yangfeng@kylinos.cn>,
	"Menglong Dong" <menglong8.dong@gmail.com>,
	"Puranjay Mohan" <puranjay@kernel.org>,
	"Björn Töpel" <bjorn@kernel.org>, "Pu Lehui" <pulehui@huawei.com>,
	linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
	netdev@vger.kernel.org, kernel-patches-bot@fb.com
Subject: Re: [PATCH bpf-next v3 3/6] bpf: Disallow !kprobe_write_ctx progs tail-calling kprobe_write_ctx progs
Date: Wed, 11 Mar 2026 23:45:30 +0100	[thread overview]
Message-ID: <abHwii5stH93Vz5E@krava> (raw)
In-Reply-To: <20260303150639.85007-4-leon.hwang@linux.dev>

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.

thanks,
jirka


> 
> Also reject kprobe_write_ctx mismatches during initialization to
> prevent bypassing the above restriction.
> 
> Without this check, the above restriction can be bypassed as follows.
> 
> struct {
> 	__uint(type, BPF_MAP_TYPE_PROG_ARRAY);
> 	__uint(max_entries, 1);
> 	__uint(key_size, 4);
> 	__uint(value_size, 4);
> } jmp_table SEC(".maps");
> 
> SEC("?kprobe")
> int prog_a(struct pt_regs *regs)
> {
> 	regs->ax = 0;
> 	bpf_tail_call_static(regs, &jmp_table, 0);
> 	return 0;
> }
> 
> SEC("?kprobe")
> int prog_b(struct pt_regs *regs)
> {
> 	bpf_tail_call_static(regs, &jmp_table, 0);
> 	return 0;
> }
> 
> The jmp_table is shared between prog_a and prog_b.
> 
> * Load prog_a.
>   At this point, owner->kprobe_write_ctx=true.
> * Load prog_b.
>   At this point, prog_b passes the compatibility check.
> * Add prog_a to jmp_table.
> * Attach prog_b to a kernel function.
> 
> When the kernel function runs, prog_a will unexpectedly modify regs.
> 
> Fixes: 7384893d970e ("bpf: Allow uprobe program to change context registers")
> Signed-off-by: Leon Hwang <leon.hwang@linux.dev>
> ---
>  include/linux/bpf.h |  7 ++++---
>  kernel/bpf/core.c   | 30 +++++++++++++++++++++++++-----
>  2 files changed, 29 insertions(+), 8 deletions(-)
> 
> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> index 05b34a6355b0..dbafed52b2ba 100644
> --- a/include/linux/bpf.h
> +++ b/include/linux/bpf.h
> @@ -285,9 +285,10 @@ struct bpf_list_node_kern {
>   */
>  struct bpf_map_owner {
>  	enum bpf_prog_type type;
> -	bool jited;
> -	bool xdp_has_frags;
> -	bool sleepable;
> +	u32 jited:1;
> +	u32 xdp_has_frags:1;
> +	u32 sleepable:1;
> +	u32 kprobe_write_ctx:1;
>  	u64 storage_cookie[MAX_BPF_CGROUP_STORAGE_TYPE];
>  	const struct btf_type *attach_func_proto;
>  	enum bpf_attach_type expected_attach_type;
> diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
> index b24a613d99f2..121a697d4da5 100644
> --- a/kernel/bpf/core.c
> +++ b/kernel/bpf/core.c
> @@ -2390,6 +2390,7 @@ static void bpf_map_owner_init(struct bpf_map_owner *owner, const struct bpf_pro
>  	owner->jited = fp->jited;
>  	owner->xdp_has_frags = aux->xdp_has_frags;
>  	owner->sleepable = fp->sleepable;
> +	owner->kprobe_write_ctx = aux->kprobe_write_ctx;
>  	owner->expected_attach_type = fp->expected_attach_type;
>  	owner->attach_func_proto = aux->attach_func_proto;
>  	for_each_cgroup_storage_type(i)
> @@ -2397,8 +2398,14 @@ static void bpf_map_owner_init(struct bpf_map_owner *owner, const struct bpf_pro
>  			aux->cgroup_storage[i]->cookie : 0;
>  }
>  
> +enum bpf_map_owner_match_type {
> +	BPF_MAP_OWNER_MATCH_FOR_INIT,
> +	BPF_MAP_OWNER_MATCH_FOR_UPDATE,
> +};
> +
>  static bool bpf_map_owner_matches(const struct bpf_map *map, const struct bpf_prog *fp,
> -				  enum bpf_prog_type prog_type)
> +				  enum bpf_prog_type prog_type,
> +				  enum bpf_map_owner_match_type match)
>  {
>  	struct bpf_map_owner *owner = map->owner;
>  	struct bpf_prog_aux *aux = fp->aux;
> @@ -2411,6 +2418,18 @@ static bool bpf_map_owner_matches(const struct bpf_map *map, const struct bpf_pr
>  	    owner->sleepable != fp->sleepable)
>  		return false;
>  
> +	switch (match) {
> +	case BPF_MAP_OWNER_MATCH_FOR_INIT:
> +		if (owner->kprobe_write_ctx != aux->kprobe_write_ctx)
> +			return false;
> +		break;
> +
> +	case BPF_MAP_OWNER_MATCH_FOR_UPDATE:
> +		if (!owner->kprobe_write_ctx && aux->kprobe_write_ctx)
> +			return false;
> +		break;
> +	}
> +
>  	if (map->map_type == BPF_MAP_TYPE_PROG_ARRAY &&
>  	    owner->expected_attach_type != fp->expected_attach_type)
>  		return false;
> @@ -2436,7 +2455,8 @@ static bool bpf_map_owner_matches(const struct bpf_map *map, const struct bpf_pr
>  }
>  
>  static bool __bpf_prog_map_compatible(struct bpf_map *map,
> -				      const struct bpf_prog *fp)
> +				      const struct bpf_prog *fp,
> +				      enum bpf_map_owner_match_type match)
>  {
>  	enum bpf_prog_type prog_type = resolve_prog_type(fp);
>  	bool ret = false;
> @@ -2453,7 +2473,7 @@ static bool __bpf_prog_map_compatible(struct bpf_map *map,
>  		bpf_map_owner_init(map->owner, fp, prog_type);
>  		ret = true;
>  	} else {
> -		ret = bpf_map_owner_matches(map, fp, prog_type);
> +		ret = bpf_map_owner_matches(map, fp, prog_type, match);
>  	}
>  err:
>  	spin_unlock(&map->owner_lock);
> @@ -2470,7 +2490,7 @@ bool bpf_prog_map_compatible(struct bpf_map *map, const struct bpf_prog *fp)
>  	if (bpf_prog_is_dev_bound(fp->aux))
>  		return false;
>  
> -	return __bpf_prog_map_compatible(map, fp);
> +	return __bpf_prog_map_compatible(map, fp, BPF_MAP_OWNER_MATCH_FOR_UPDATE);
>  }
>  
>  static int bpf_check_tail_call(const struct bpf_prog *fp)
> @@ -2485,7 +2505,7 @@ static int bpf_check_tail_call(const struct bpf_prog *fp)
>  		if (!map_type_contains_progs(map))
>  			continue;
>  
> -		if (!__bpf_prog_map_compatible(map, fp)) {
> +		if (!__bpf_prog_map_compatible(map, fp, BPF_MAP_OWNER_MATCH_FOR_INIT)) {
>  			ret = -EINVAL;
>  			goto out;
>  		}
> -- 
> 2.52.0
> 

  parent reply	other threads:[~2026-03-11 22:45 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-03 15:06 [PATCH bpf-next v3 0/6] bpf: Enhance __bpf_prog_map_compatible() Leon Hwang
2026-03-03 15:06 ` [PATCH bpf-next v3 1/6] bpf: Add fsession to verbose log in check_get_func_ip() Leon Hwang
2026-03-03 15:06 ` [PATCH bpf-next v3 2/6] bpf: Factor out bpf_map_owner_[init,matches]() helpers Leon Hwang
2026-03-03 15:06 ` [PATCH bpf-next v3 3/6] bpf: Disallow !kprobe_write_ctx progs tail-calling kprobe_write_ctx progs Leon Hwang
2026-03-03 16:01   ` bot+bpf-ci
2026-03-10 17:23     ` Kumar Kartikeya Dwivedi
2026-03-11  6:08       ` Leon Hwang
2026-03-11  9:21         ` Kumar Kartikeya Dwivedi
2026-03-11 15:44           ` Alexei Starovoitov
2026-03-11 16:00             ` Leon Hwang
2026-03-11 22:45   ` Jiri Olsa [this message]
2026-03-12  2:24     ` Leon Hwang
2026-03-12 10:46       ` Jiri Olsa
2026-03-12 13:39         ` Leon Hwang
2026-03-03 15:06 ` [PATCH bpf-next v3 4/6] bpf: Disallow !call_get_func_ip progs tail-calling call_get_func_ip progs Leon Hwang
2026-03-03 15:06 ` [PATCH bpf-next v3 5/6] bpf: Disallow !call_session_cookie progs tail-calling call_session_cookie progs Leon Hwang
2026-03-03 15:06 ` [PATCH bpf-next v3 6/6] selftests/bpf: Add tests to verify prog_array map compatibility Leon Hwang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=abHwii5stH93Vz5E@krava \
    --to=olsajiri@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bjorn@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=haoluo@google.com \
    --cc=john.fastabend@gmail.com \
    --cc=kernel-patches-bot@fb.com \
    --cc=kpsingh@kernel.org \
    --cc=leon.hwang@linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=menglong8.dong@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pulehui@huawei.com \
    --cc=puranjay@kernel.org \
    --cc=sdf@fomichev.me \
    --cc=shuah@kernel.org \
    --cc=song@kernel.org \
    --cc=yangfeng@kylinos.cn \
    --cc=yonghong.song@linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox