All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Amery Hung" <ameryhung@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v3 15/18] bpf: Classify kfunc pointer arguments from BTF, resolve type against the register
Date: Sat, 01 Aug 2026 08:22:45 +0000	[thread overview]
Message-ID: <20260801082246.17FB41F00AC4@smtp.kernel.org> (raw)
In-Reply-To: <20260801074633.1595644-16-ameryhung@gmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Allowing PTR_TO_BTF_ID as a KF_ARG_PTR_TO_MEM argument is either broken or fundamentally unsafe due to unvalidated access flags.
--

--- Patch [15]: [PATCH bpf-next v3 15/18] bpf: Classify kfunc pointer arguments from BTF, resolve type against the register ---
commit d5adf1f80d7ac5827091492c5099bcb0c05e15d1
Author: Amery Hung <ameryhung@gmail.com>

bpf: Classify kfunc pointer arguments from BTF, resolve type against the register

This commit changes kfunc pointer argument classification to rely strictly
on BTF rather than register state. It introduces support for passing a
PTR_TO_BTF_ID as a fixed-size memory buffer when pointing to a scalar struct.

>     The new design now accepts one previously rejected case: passing
>     PTR_TO_BTF_ID to a pointer to scalar w/o a following __sz/__szk. The
>     argument will be classified as KF_ARG_PTR_TO_MEM | MEM_FIXED_SIZE. The
>     PTR_TO_BTF_ID register will go through check_mem_reg() ->
>     check_helper_mem_access() -> check_ptr_to_btf_access(), and by default only
>     read is allowed.

[Severity: Medium]
Will this newly accepted case always fail verification?

While the commit message states that "by default only read is allowed,"
the call to check_mem_reg() for KF_ARG_PTR_TO_MEM arguments
unconditionally demands BPF_READ | BPF_WRITE access. This causes
check_ptr_to_btf_access() to reject standard kernel pointers with -EACCES.

> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 1ccf3b764c515..9045369ba5694 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -11405,37 +11414,37 @@ get_kfunc_ptr_arg_type(struct bpf_verifier_env *env,
[ ... ]
> -	/* This is the catch all argument type of register types supported by
> -	 * check_helper_mem_access. However, we only allow when argument type is
> -	 * pointer to scalar, or struct composed (recursively) of scalars. When
> -	 * arg_mem_size is true, the pointer can be void *.
> +	/* A pointer to a struct without a size argument is classified as KF_ARG_PTR_TO_BTF_ID */
> +	if (btf_type_is_struct(ref_t))
> +		return KF_ARG_PTR_TO_BTF_ID;
> +
> +	/*
> +	 * Otherwise this is a fixed-size memory buffer supported by
> +	 * check_helper_mem_access(): a pointer to a scalar or a struct of
> +	 * scalars. The access size is derived from the pointed-to BTF type.
>  	 */
> -	if (!btf_type_is_scalar(ref_t) && !__btf_type_is_scalar_struct(env, meta->btf, ref_t, 0) &&
> -	    (arg_mem_size ? !btf_type_is_void(ref_t) : 1)) {
> -		verbose(env, "%s pointer type %s %s must point to %sscalar, or struct with scalar\n",
> -			reg_arg_name(env, argno),
> -			btf_type_str(ref_t), ref_tname, arg_mem_size ? "void, " : "");
> +	if (!btf_type_is_scalar(ref_t) &&
> +	    !__btf_type_is_scalar_struct(env, meta->btf, ref_t, 0)) {
> +		verbose(env, "%s pointer type %s %s must point to scalar, or struct with scalar\n",
> +			reg_arg_name(env, argno), btf_type_str(ref_t), ref_tname);
>  		return -EINVAL;
>  	}
> -	return arg_mem_size ? KF_ARG_PTR_TO_MEM : KF_ARG_PTR_TO_MEM | MEM_FIXED_SIZE;
> +	return KF_ARG_PTR_TO_MEM | MEM_FIXED_SIZE;
>  }

[Severity: Medium]
When get_kfunc_ptr_arg_type() returns KF_ARG_PTR_TO_MEM | MEM_FIXED_SIZE for
a PTR_TO_BTF_ID, or when check_kfunc_args() falls through to KF_ARG_PTR_TO_MEM,
it verifies the argument as a memory buffer:

kernel/bpf/verifier.c:check_kfunc_args() {
    ...
		case KF_ARG_PTR_TO_MEM:
			if (kf_arg_type & MEM_FIXED_SIZE) {
				resolve_ret = btf_resolve_size(btf, ref_t, &type_size);
                ...
				ret = check_mem_reg(env, reg, argno, type_size, BPF_READ | BPF_WRITE, meta);
    ...
}

Because check_mem_reg() is passed BPF_READ | BPF_WRITE, it requires write
access. When this goes through check_helper_mem_access() and reaches
check_ptr_to_btf_access(), it will be rejected because atype != BPF_READ:

kernel/bpf/verifier.c:check_ptr_to_btf_access() {
    ...
		if (atype != BPF_READ && !type_is_ptr_alloc_obj(reg->type)) {
			verbose(env, "only read is supported\n");
			return -EACCES;
		}
    ...
}

Could this unconditionally break the newly introduced feature for standard
(non-allocated) kernel pointers? Also, if the BPF_READ | BPF_WRITE flag were
simply changed to BPF_READ to pass verification, could it introduce a
vulnerability since the verifier cannot guarantee that the underlying kfunc
will not write to the buffer?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260801074633.1595644-1-ameryhung@gmail.com?part=15

  reply	other threads:[~2026-08-01  8:22 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-01  7:46 [PATCH bpf-next v3 00/18] Generate bpf_func_proto for kfunc Amery Hung
2026-08-01  7:46 ` [PATCH bpf-next v3 01/18] bpf: Drop process_timer_func wrappers Amery Hung
2026-08-01  7:46 ` [PATCH bpf-next v3 02/18] bpf: Unify const map ptr argument checking for helpers and kfuncs Amery Hung
2026-08-01  8:03   ` sashiko-bot
2026-08-01  7:46 ` [PATCH bpf-next v3 03/18] bpf: Split kfunc map argument into __const_map and __map Amery Hung
2026-08-01  7:46 ` [PATCH bpf-next v3 04/18] bpf: Pass kfunc meta to mem and mem_size check Amery Hung
2026-08-01  7:46 ` [PATCH bpf-next v3 05/18] bpf: Resolve map lookup result type at lookup time Amery Hung
2026-08-01  7:46 ` [PATCH bpf-next v3 06/18] bpf: Check helper and kfunc mem+size arguments identically Amery Hung
2026-08-01  7:46 ` [PATCH bpf-next v3 07/18] selftests/bpf: Test map lookup result refinement Amery Hung
2026-08-01  7:46 ` [PATCH bpf-next v3 08/18] bpf: Check fixed-size mem args of helpers and kfuncs the same way Amery Hung
2026-08-01  8:17   ` sashiko-bot
2026-08-01  7:46 ` [PATCH bpf-next v3 09/18] bpf: Rename ARG_CONST_SIZE{,_OR_ZERO} to ARG_MEM_SIZE{,_OR_ZERO} Amery Hung
2026-08-01  7:46 ` [PATCH bpf-next v3 10/18] bpf: Fold __szk const size handling into the scalar arg path Amery Hung
2026-08-01  7:46 ` [PATCH bpf-next v3 11/18] selftests/bpf: Test __szk precision with a NULL nullable buffer Amery Hung
2026-08-01  7:46 ` [PATCH bpf-next v3 12/18] bpf: Classify kfunc mem_size args from BTF without register state Amery Hung
2026-08-01  8:09   ` sashiko-bot
2026-08-01  7:46 ` [PATCH bpf-next v3 13/18] bpf: Handle NULL kfunc pointer args without a KF_ARG_PTR_TO_NULL type Amery Hung
2026-08-01  7:46 ` [PATCH bpf-next v3 14/18] bpf: Distinguish fixed- and variable-size kfunc mem args with MEM_FIXED_SIZE Amery Hung
2026-08-01  7:46 ` [PATCH bpf-next v3 15/18] bpf: Classify kfunc pointer arguments from BTF, resolve type against the register Amery Hung
2026-08-01  8:22   ` sashiko-bot [this message]
2026-08-01  7:46 ` [PATCH bpf-next v3 16/18] bpf: Tag nullable kfunc pointer args with PTR_MAYBE_NULL Amery Hung
2026-08-01  7:46 ` [PATCH bpf-next v3 17/18] bpf: Classify scalar kfunc arguments from BTF Amery Hung
2026-08-01  7:46 ` [PATCH bpf-next v3 18/18] bpf: Generate kfunc argument prototype at add-call time Amery Hung

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=20260801082246.17FB41F00AC4@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=ameryhung@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=sashiko-reviews@lists.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.