[bug report] bpf, x86: add support for indirect jumps

[bug report] bpf, x86: add support for indirect jumps

[Dan Carpenter]

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).

    17908         }
    17909         return 0;
    17910 }

regards,
dan carpenter

Re: [bug report] bpf, x86: add support for indirect jumps

[Anton Protopopov]

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.

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

Re: [bug report] bpf, x86: add support for indirect jumps

[Dan Carpenter]

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