BPF List
 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 02/18] bpf: Unify const map ptr argument checking for helpers and kfuncs
Date: Sat, 01 Aug 2026 08:03:18 +0000	[thread overview]
Message-ID: <20260801080319.0E9C51F00AC4@smtp.kernel.org> (raw)
In-Reply-To: <20260801074633.1595644-3-ameryhung@gmail.com>

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] Latent NULL Pointer Dereference in process_map_ptr_arg
- [Low] Incorrect error reporting for non-adjacent object and map arguments
- [Low] Misleading error message when a map contains both a timer and a workqueue
--

--- Patch [2]: [PATCH bpf-next v3 02/18] bpf: Unify const map ptr argument checking for helpers and kfuncs ---
commit 28f78cdb3fca90eedfb38c316b9b1e6ce726d4a2
Author: Amery Hung <ameryhung@gmail.com>

bpf: Unify const map ptr argument checking for helpers and kfuncs

This patch refactors the verifier to use a single process_map_ptr_arg()
function for validating constant map pointer arguments in both helpers and
kfuncs. The new logic attempts to dynamically derive the bound object name
from the map's BTF record and computes the register numbers relative to
the map argument position.

> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 616194f25dfb7..4a5b542192106 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c

[ ... ]

> @@ -8274,6 +8274,44 @@ static int get_constant_map_key(struct bpf_verifier_env *env,
>  
>  static bool can_elide_value_nullness(const struct bpf_map *map);
>  
> +static int process_map_ptr_arg(struct bpf_verifier_env *env, struct bpf_reg_state *reg,
> +			       argno_t argno, struct bpf_call_arg_meta *meta)
> +{
> +	/* Use map_uid (which is unique id of inner map) to reject:
> +	 * inner_map1 = bpf_map_lookup_elem(outer_map, key1)
> +	 * inner_map2 = bpf_map_lookup_elem(outer_map, key2)
> +	 * if (inner_map1 && inner_map2) {
> +	 *     timer = bpf_map_lookup_elem(inner_map1);
> +	 *     if (timer)
> +	 *         // mismatch would have been allowed
> +	 *         bpf_timer_init(timer, inner_map2);
> +	 * }
> +	 *
> +	 * Comparing map_ptr is enough to distinguish normal and outer maps.
> +	 */
> +	if (meta->map.ptr &&
> +	    (meta->map.ptr != reg->map_ptr || meta->map.uid != reg->map_uid)) {
> +		argno_t obj_argno = argno_from_reg(reg_from_argno(argno) - 1);

[Severity: Low]
Does this incorrectly assume the bound object strictly precedes the map
argument in all function signatures?

If a custom module kfunc interleaves arguments (e.g., passing a flag between
the object and the map) or if the map is passed on the stack, this arithmetic
will yield the wrong register or a negative value.  For instance, if the map
is the first argument, it might calculate negative registers and print
garbage like fp-1992 in the verifier log.

> +		struct btf_record *rec = meta->map.ptr->record;
> +		const char *obj_name = "workqueue";
> +
> +		if (rec->timer_off >= 0)

[Severity: Medium]
Can this unconditionally dereference rec when it is NULL?

If the verifier processes a kfunc that takes multiple map pointers (e.g., in a
custom module), the first map passed is tracked in meta->map.ptr. If that first
map is a simple array or hash map without any special BTF fields, its record
will be NULL. When the verifier processes the second map argument and it
mismatches, it will hit this check and crash due to a NULL pointer dereference.

[Severity: Low]
Will this produce misleading error messages if a map contains both a timer and
a workqueue?

A BPF map value can validly contain both a bpf_timer and a bpf_wq, meaning its
btf_record will have both timer_off >= 0 and wq_off >= 0 true. 

If a user calls bpf_wq_init() but accidentally passes a mismatched map, this
conditional guesses the object type purely from the map's record and prioritizes
the timer field. It will incorrectly print an error about a timer pointer
mismatch, which would mislead the user who was explicitly working with a
workqueue.

> +			obj_name = "timer";
> +		else if (rec->task_work_off >= 0)
> +			obj_name = "bpf_task_work";
> +
> +		verbose(env, "%s pointer in %s map_uid=%d ",
> +			obj_name, reg_arg_name(env, obj_argno), meta->map.uid);
> +		verbose(env, "doesn't match map pointer in %s map_uid=%d\n",
> +			reg_arg_name(env, argno), reg->map_uid);
> +		return -EINVAL;
> +	}
> +
> +	meta->map.ptr = reg->map_ptr;
> +	meta->map.uid = reg->map_uid;
> +	return 0;
> +}

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

  reply	other threads:[~2026-08-01  8:03 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 [this message]
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
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=20260801080319.0E9C51F00AC4@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox