mirror of
https://github.com/torvalds/linux
synced 2024-09-06 01:40:28 +00:00
libbpf: Prevent null-pointer dereference when prog to load has no BTF
In bpf_objec_load_prog(), there's no guarantee that obj->btf is non-NULL
when passing it to btf__fd(), and this function does not perform any
check before dereferencing its argument (as bpf_object__btf_fd() used to
do). As a consequence, we get segmentation fault errors in bpftool (for
example) when trying to load programs that come without BTF information.
v2: Keep btf__fd() in the fix instead of reverting to bpf_object__btf_fd().
Fixes: df7c3f7d3a
("libbpf: make uniform use of btf__fd() accessor inside libbpf")
Suggested-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Quentin Monnet <qmo@kernel.org>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20240314150438.232462-1-qmo@kernel.org
This commit is contained in:
parent
fe879bb42f
commit
9bf48fa19a
|
@ -7317,9 +7317,9 @@ static int bpf_object_load_prog(struct bpf_object *obj, struct bpf_program *prog
|
|||
char *cp, errmsg[STRERR_BUFSIZE];
|
||||
size_t log_buf_size = 0;
|
||||
char *log_buf = NULL, *tmp;
|
||||
int btf_fd, ret, err;
|
||||
bool own_log_buf = true;
|
||||
__u32 log_level = prog->log_level;
|
||||
int ret, err;
|
||||
|
||||
if (prog->type == BPF_PROG_TYPE_UNSPEC) {
|
||||
/*
|
||||
|
@ -7343,9 +7343,8 @@ static int bpf_object_load_prog(struct bpf_object *obj, struct bpf_program *prog
|
|||
load_attr.prog_ifindex = prog->prog_ifindex;
|
||||
|
||||
/* specify func_info/line_info only if kernel supports them */
|
||||
btf_fd = btf__fd(obj->btf);
|
||||
if (btf_fd >= 0 && kernel_supports(obj, FEAT_BTF_FUNC)) {
|
||||
load_attr.prog_btf_fd = btf_fd;
|
||||
if (obj->btf && btf__fd(obj->btf) >= 0 && kernel_supports(obj, FEAT_BTF_FUNC)) {
|
||||
load_attr.prog_btf_fd = btf__fd(obj->btf);
|
||||
load_attr.func_info = prog->func_info;
|
||||
load_attr.func_info_rec_size = prog->func_info_rec_size;
|
||||
load_attr.func_info_cnt = prog->func_info_cnt;
|
||||
|
|
Loading…
Reference in a new issue