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 v1 03/18] bpf: Split kfunc map argument into __const_map and __map
Date: Thu, 23 Jul 2026 05:35:02 +0000	[thread overview]
Message-ID: <20260723053502.B40831F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260723050806.1158442-4-ameryhung@gmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] The newly introduced `KF_ARG_CONST_MAP_PTR` logic fails to verify that the register's base type is `CONST_PTR_TO_MAP`. Any register with a non-zero union aliasing `map_ptr` (such as `PTR_TO_MAP_VALUE`) can bypass validation, leading to severe type confusion at runtime where user-controlled map value memory is treated as a `struct bpf_map *`.
--

--- Patch [3]: [PATCH bpf-next v1 03/18] bpf: Split kfunc map argument into __const_map and __map ---
commit 2aa2cd575b3d4be283e92e30e814910f54fbe0cc
Author: Amery Hung <ameryhung@gmail.com>

bpf: Split kfunc map argument into __const_map and __map

This commit splits the kfunc map argument annotation to avoid type confusion.
__const_map indicates a verifier-known map, while __map indicates an opaque
struct bpf_map resolved at runtime.

> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index bff51aff25579..0ba0de8eb8fe0 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
[ ... ]
> @@ -12164,6 +12168,7 @@ static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_call_arg_me
>  				}
>  			}
>  			fallthrough;
> +		case KF_ARG_CONST_MAP_PTR:
>  		case KF_ARG_PTR_TO_ITER:
>  		case KF_ARG_PTR_TO_LIST_HEAD:
>  		case KF_ARG_PTR_TO_LIST_NODE:

[Severity: Critical]
Does this skip the is_trusted_reg() checks and leave arg_type as ARG_DONTCARE?
Since KF_ARG_CONST_MAP_PTR falls through to the break below, it seems we might
bypass pointer type safety enforcement here.

[ ... ]
> @@ -12371,12 +12376,16 @@ static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_call_arg_me
>  			if (ret < 0)
>  				return ret;
>  			break;
> -		case KF_ARG_PTR_TO_MAP:
> -			/* If argument has '__map' suffix expect 'struct bpf_map *' */
> -			ref_id = *reg2btf_ids[CONST_PTR_TO_MAP];
> -			ref_t = btf_type_by_id(btf_vmlinux, ref_id);
> -			ref_tname = btf_name_by_offset(btf, ref_t->name_off);
> -			fallthrough;
> +		case KF_ARG_CONST_MAP_PTR:
> +			if (!reg->map_ptr) {
> +				verbose(env, "pointer in %s isn't map pointer\n",
> +					reg_arg_name(env, argno));
> +				return -EINVAL;
> +			}
> +			ret = process_map_ptr_arg(env, reg, argno, meta);
> +			if (ret < 0)
> +				return ret;
> +			break;

[Severity: Critical]
Is there a missing check for base_type(reg->type) == CONST_PTR_TO_MAP here?

Since this breaks instead of falling through to KF_ARG_PTR_TO_BTF_ID like the
old code did, it looks like any register with a non-zero union aliasing
map_ptr (such as PTR_TO_MAP_VALUE) can bypass validation.

For example, could a BPF program call bpf_wq_init(wq, map__const_map, flags)
and pass a PTR_TO_MAP_VALUE for both the wq and map__const_map arguments?

If wq and map__const_map use the same register, process_map_ptr_arg() would
verify meta->map.ptr == reg->map_ptr (which evaluates to true), and then break
out without ever verifying the register type. This would cause the kernel to
treat user-controlled bytes inside a map value as a kernel struct bpf_map
object, potentially leading to memory corruption.

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

  reply	other threads:[~2026-07-23  5:35 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-23  5:07 [PATCH bpf-next v1 00/18] Generate bpf_func_proto for kfunc Amery Hung
2026-07-23  5:07 ` [PATCH bpf-next v1 01/18] bpf: Drop process_timer_func wrappers Amery Hung
2026-07-23  5:07 ` [PATCH bpf-next v1 02/18] bpf: Unify const map ptr argument checking for helpers and kfuncs Amery Hung
2026-07-23  5:25   ` sashiko-bot
2026-07-23  5:07 ` [PATCH bpf-next v1 03/18] bpf: Split kfunc map argument into __const_map and __map Amery Hung
2026-07-23  5:35   ` sashiko-bot [this message]
2026-07-23  5:07 ` [PATCH bpf-next v1 04/18] bpf: Pass kfunc meta to mem and mem_size check Amery Hung
2026-07-23  5:07 ` [PATCH bpf-next v1 05/18] bpf: Check helper and kfunc mem+size arguments identically Amery Hung
2026-07-23  5:52   ` sashiko-bot
2026-07-23  5:07 ` [PATCH bpf-next v1 06/18] selftests/bpf: Add tests for helper and kfunc mem+size arguments Amery Hung
2026-07-23  5:42   ` sashiko-bot
2026-07-23  5:07 ` [PATCH bpf-next v1 07/18] bpf: Check fixed-size mem args of helpers and kfuncs the same way Amery Hung
2026-07-23  5:57   ` sashiko-bot
2026-07-23  5:07 ` [PATCH bpf-next v1 08/18] bpf: Express ARG_CONST_SIZE_OR_ZERO as ARG_CONST_SIZE | SCALAR_MAYBE_ZERO Amery Hung
2026-07-23  5:07 ` [PATCH bpf-next v1 09/18] bpf: Rename ARG_CONST_SIZE{,_OR_ZERO} to ARG_MEM_SIZE{,_OR_ZERO} Amery Hung
2026-07-23  5:07 ` [PATCH bpf-next v1 10/18] bpf: Fold __szk const size handling into the scalar arg path Amery Hung
2026-07-23  5:07 ` [PATCH bpf-next v1 11/18] bpf: Classify kfunc mem_size args from BTF without register state Amery Hung
2026-07-23  5:08 ` [PATCH bpf-next v1 12/18] bpf: Handle NULL kfunc pointer args without a KF_ARG_PTR_TO_NULL type Amery Hung
2026-07-23  5:08 ` [PATCH bpf-next v1 13/18] bpf: Distinguish fixed- and variable-size kfunc mem args with MEM_FIXED_SIZE Amery Hung
2026-07-23  5:08 ` [PATCH bpf-next v1 14/18] bpf: Check helper mem+size in ARG_PTR_TO_MEM case Amery Hung
2026-07-23  5:08 ` [PATCH bpf-next v1 15/18] bpf: Classify kfunc pointer arguments from BTF, resolve type against the register Amery Hung
2026-07-23  7:27   ` sashiko-bot
2026-07-23  5:08 ` [PATCH bpf-next v1 16/18] bpf: Tag nullable kfunc pointer args with PTR_MAYBE_NULL Amery Hung
2026-07-23  5:08 ` [PATCH bpf-next v1 17/18] bpf: Classify scalar kfunc arguments from BTF Amery Hung
2026-07-23  8:01   ` sashiko-bot
2026-07-23  5:08 ` [PATCH bpf-next v1 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=20260723053502.B40831F000E9@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.