public inbox for bpf@vger.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@linaro.org>
To: Anton Protopopov <a.s.protopopov@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [bug report] bpf, x86: add support for indirect jumps
Date: Wed, 19 Nov 2025 15:48:30 +0300	[thread overview]
Message-ID: <aR28nuYIPPL-89lG@stanley.mountain> (raw)
In-Reply-To: <aR2n7mrFwjucPsYm@mail.gmail.com>

On Wed, Nov 19, 2025 at 11:20:14AM +0000, Anton Protopopov wrote:
> On 25/11/19 11:35AM, Dan Carpenter wrote:
> > Hello Anton Protopopov,
> > 
> > Commit 493d9e0d6083 ("bpf, x86: add support for indirect jumps") from
> > Nov 5, 2025 (linux-next), leads to the following Smatch static
> > checker warning:
> > 
> > 	kernel/bpf/verifier.c:17907 copy_insn_array()
> > 	error: 'value' dereferencing possible ERR_PTR()
> > 
> > kernel/bpf/verifier.c
> >     17898 static int copy_insn_array(struct bpf_map *map, u32 start, u32 end, u32 *items)
> >     17899 {
> >     17900         struct bpf_insn_array_value *value;
> >     17901         u32 i;
> >     17902 
> >     17903         for (i = start; i <= end; i++) {
> >     17904                 value = map->ops->map_lookup_elem(map, &i);
> >     17905                 if (!value)
> >     17906                         return -EINVAL;
> > --> 17907                 items[i - start] = value->xlated_off;
> > 
> > ->map_lookup_elem() returns error pointers on error and it returns NULL
> > (I guess if there isn't an error but the element is not found).
> 
> I didn't check the value here, because in this case map_lookup_elem()
> always returns a correct value or NULL (= index is outside of boundaries).
> 
> >From BPF point of view, map_lookup_elem must return valid pointer, or
> null (see the bpf_map_lookup_elem_proto in kernel/bpf/helpers.c). But
> some lookup functions might be called from kernel (as in this case)
> or from userspace via the syscall. So I'll send a fix to add a check
> here and make the static checker happy.
> 

I wondered if this might be the case.  If you don't want to, you don't
have to add an IS_ERR() check, but I think a comment would help.
Otherwise people with questions could just find this email here.

Generally, in the kernel we assume that all old static checker warnings
have been addressed so anything remaining is a false positive.

regards,
dan carpenter

> >     17908         }
> >     17909         return 0;
> >     17910 }
> > 
> > regards,
> > dan carpenter

      reply	other threads:[~2025-11-19 12:48 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-19  8:35 [bug report] bpf, x86: add support for indirect jumps Dan Carpenter
2025-11-19 11:20 ` Anton Protopopov
2025-11-19 12:48   ` Dan Carpenter [this message]

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=aR28nuYIPPL-89lG@stanley.mountain \
    --to=dan.carpenter@linaro.org \
    --cc=a.s.protopopov@gmail.com \
    --cc=bpf@vger.kernel.org \
    /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