summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python
diff options
context:
space:
mode:
authorJosef Bacik <josef@toxicpanda.com>2026-10-17 16:37:28 +0000
committerAlexei Starovoitov <ast@kernel.org>2026-10-17 22:01:14 +0000
commit7cc639dc45c5d3b69acb2a2fc834e9eec51e0214 (patch)
treeca0cc3876a2009db8a07287481850ce6dee45828 /tools/perf/scripts/python
parent7fa323d77688e8b62b2f0bf6c3208a2c96d4a5e7 (diff)
bpf: Don't take an extension for an iterator program
An extension inherits the expected_attach_type of the program it extends. If that is BPF_TRACE_ITER, check_attach_btf_id() hands the extension to bpf_iter_prog_supported(), which goes by the name of the attach function. For an extension that is the name of the subprogram it replaces, so the load fails with -EINVAL, unless that subprogram is called like the function of a target, bpf_iter_bpf_map_elem for example. Then the extension gets the context of that target. If the subprogram has as many arguments, it can use the key and the value as buffers, but how far it reaches is noted in the extension, where the test of the iterator link does not look: it reads and writes behind the elements of the map. And the id of the subprogram in the BTF of the program is cached as the id of the target, so that programs of that target which are loaded already cannot be attached. Refuse all extensions here. Fixes: 15d83c4d7cef ("bpf: Allow loading of a bpf_iter program") Signed-off-by: Josef Bacik <josef@toxicpanda.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://patch.msgid.link/20261017163745.3341787-27-alexei.starovoitov@gmail.com
Diffstat (limited to 'tools/perf/scripts/python')
0 files changed, 0 insertions, 0 deletions