All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Avinash Pal" <avinashpal441@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH] bpf: verifier: fix NULL deref in map_kptr_match_type() for scalar regs
Date: Mon, 20 Apr 2026 04:00:37 +0000	[thread overview]
Message-ID: <20260420040038.5396BC19425@smtp.kernel.org> (raw)
In-Reply-To: <20260419035948.9498-1-avinashpal441@gmail.com>

Sashiko AI review found 2 potential issue(s):
- [Medium] Invalid union access and type punning due to unverified `reg->btf` read.
- [Medium] Flawed bug diagnosis; patch addresses a structurally unreachable code path.
--

commit ce0e8cc557a90340c0553cc6fd6f929375190b78
Author: Avinash Pal <avinashpal441@gmail.com>

bpf: verifier: fix NULL deref in map_kptr_match_type() for scalar regs

This commit adds an early NULL check for the register BTF field in
map_kptr_match_type() to prevent an alleged NULL pointer dereference
when a scalar value is evaluated.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=221372

> Call chain:
>   check_store_reg()
>     -> check_mem_access()
>        -> check_map_kptr_access()
>           -> map_kptr_match_type()
>              -> btf_is_kernel(reg->btf)   <-- NULL deref
>
> For scalar registers reg->btf is NULL. map_kptr_match_type() passes
> this directly to btf_is_kernel(), which performs a container_of()-based
> offset access and triggers a general protection fault:

Is this sequence actually possible in the unpatched code?

Looking at map_kptr_match_type(), the base register type is checked
before btf_is_kernel() is ever called:

    if (base_type(reg->type) != PTR_TO_BTF_ID)
        goto bad_type;

    if (btf_is_kernel(reg->btf)) {
        ...

For a scalar register, base_type(reg->type) evaluates to SCALAR_VALUE,
causing it to fail the PTR_TO_BTF_ID check and jump to the bad_type label
without evaluating btf_is_kernel(reg->btf).

> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 69d75515ed3f7..15b8f71074f93 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -4545,6 +4545,18 @@ static int map_kptr_match_type(struct bpf_verifier_env *env,
>  			       struct btf_field *kptr_field,
>  			       struct bpf_reg_state *reg, u32 regno)
>  {
> +	/*
> +	 * If the source register has no BTF type (e.g. it is a scalar),
> +	 * it cannot possibly match a kptr slot. Reject early to avoid
> +	 * passing a NULL reg->btf to btf_is_kernel(), which would cause
> +	 * a NULL pointer dereference inside that function.
> +	 */
> +	if (!reg->btf) {

Is it safe to access reg->btf before verifying the register type?

In struct bpf_reg_state, the btf pointer is part of an anonymous union
and shares memory with fields used by other register types, such as
range for PTR_TO_PACKET or mem_size for PTR_TO_MEM.

If a non-BTF register is evaluated and its aliased memory happens to be 0
(for example, a packet pointer with range == 0), could this incorrectly
trigger the early exit with -EACCES? This would bypass the expected type
mismatch handling and -EINVAL return code in the bad_type block.

> +		verbose(env, "R%d is not a pointer, cannot store into kptr slot\n",
> +			regno);
> +		return -EACCES;
> +	}
> +
>  	const char *targ_name = btf_type_name(kptr_field->kptr.btf, kptr_field->kptr.btf_id);

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

  reply	other threads:[~2026-04-20  4:00 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-19  3:59 [PATCH] bpf: verifier: fix NULL deref in map_kptr_match_type() for scalar regs Avinash Pal
2026-04-20  4:00 ` sashiko-bot [this message]
  -- strict thread matches above, loose matches on Subject: below --
2026-04-19  4:04 Avinash Pal
2026-04-19  4:32 ` bot+bpf-ci
2026-04-19  5:01   ` sun jian
2026-04-20  4:05 ` sashiko-bot

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=20260420040038.5396BC19425@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=avinashpal441@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=sashiko@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.