diff options
author | 2024-07-24 12:14:58 -0500 | |
---|---|---|
committer | 2024-07-29 15:05:09 -0700 | |
commit | 04a94133f1b3cccb19e056c26f056c50b4e5b3b1 (patch) | |
tree | 1a280d498a08845bc770453ddbba636c974f1c76 /tools/perf/scripts/python/export-to-postgresql.py | |
parent | Merge branch 'selftests-bpf-improve-libc-portability-musl-support-part-1' (diff) | |
download | wireguard-linux-04a94133f1b3cccb19e056c26f056c50b4e5b3b1.tar.xz wireguard-linux-04a94133f1b3cccb19e056c26f056c50b4e5b3b1.zip |
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
Diffstat (limited to 'tools/perf/scripts/python/export-to-postgresql.py')
0 files changed, 0 insertions, 0 deletions