On 1/31/24 10:26 PM, Eduard Zingerman wrote:
After recent changes, Coverity complained about inconsistent null
checks in kernel_supports() function:
kernel_supports(const struct bpf_object *obj, ...)
...
// var_compare_op: Comparing obj to null implies that obj might be null
if (obj && obj->gen_loader)
return true;
// var_deref_op: Dereferencing null pointer obj
if (obj->token_fd)
return feat_supported(obj->feat_cache, feat_id);
...
- The original null check was introduced by commit [0],
which introduced a call `kernel_supports(NULL, ...)`
in function bump_rlimit_memlock();
- This call was refactored to use `feat_supported(NULL, ...)`
in commit [1].
Looking at all places where kernel_supports() is called:
- there is either `obj->...` access before the call;
- or `obj` comes from `prog->obj` expression, where `prog` comes from
enumeration of programs in `obj`;
- or `obj` comes from `prog->obj`, where `prog` is a parameter to one
of the API functions:
- bpf_program__attach_kprobe_opts;
- bpf_program__attach_kprobe;
- bpf_program__attach_ksyscall.
Assuming correct API usage, it appears that `obj` can never be null
when passed to kernel_supports(). Silence the Coverity warning by
removing redundant null check.
[0] e542f2c4cd16 ("libbpf: Auto-bump RLIMIT_MEMLOCK if kernel needs it for BPF")
[1] d6dd1d49367a ("libbpf: Further decouple feature checking logic from bpf_object")
Signed-off-by: Eduard Zingerman <eddyz87@xxxxxxxxx>
lgtm, also on the latter the struct bpf_program is only defined in libbpf.c, and
you can only use libbpf.h APIs to retrieve a pointer of this type from the obj.
