libbpf: Don't take direct pointers into BTF data from st_ops
authorDavid Vernet <void@manifault.com>
Wed, 24 Jul 2024 17:14:58 +0000 (12:14 -0500)
committerAndrii Nakryiko <andrii@kernel.org>
Mon, 29 Jul 2024 22:05:09 +0000 (15:05 -0700)
commit04a94133f1b3cccb19e056c26f056c50b4e5b3b1
tree1a280d498a08845bc770453ddbba636c974f1c76
parent8efffab4e54f3e055c86ced2ad3299d6d96f4a39
libbpf: Don't take direct pointers into BTF data from st_ops

In struct bpf_struct_ops, we have take a pointer to a BTF type name, and
a struct btf_type. This was presumably done for convenience, but can
actually result in subtle and confusing bugs given that BTF data can be
invalidated before a program is loaded. For example, in sched_ext, we
may sometimes resize a data section after a skeleton has been opened,
but before the struct_ops scheduler map has been loaded. This may cause
the BTF data to be realloc'd, which can then cause a UAF when loading
the program because the struct_ops map has pointers directly into the
BTF data.

We're already storing the BTF type_id in struct bpf_struct_ops. Because
type_id is stable, we can therefore just update the places where we were
looking at those pointers to instead do the lookups we need from the
type_id.

Fixes: 590a00888250 ("bpf: libbpf: Add STRUCT_OPS support")
Signed-off-by: David Vernet <void@manifault.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20240724171459.281234-1-void@manifault.com
tools/lib/bpf/libbpf.c