]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
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)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Fri, 4 Oct 2024 14:32:53 +0000 (16:32 +0200)
commitec9a805d01befb3d219824ae49d833abffef9308
treeaff405f66e9147fe06b0e3ef6c15d292328a0e60
parent0b0a37b18c642b74754c5ff2cf15c951860b3a8d
libbpf: Don't take direct pointers into BTF data from st_ops

[ Upstream commit 04a94133f1b3cccb19e056c26f056c50b4e5b3b1 ]

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
Signed-off-by: Sasha Levin <sashal@kernel.org>
tools/lib/bpf/libbpf.c