> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index d92cf2821657..832a87da5a86 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
[ ... ]
> @@ -25173,6 +25181,8 @@ int bpf_check_attach_target(struct bpf_verifier_log
> *log,
> case BPF_TRACE_FENTRY:
> case BPF_TRACE_FEXIT:
> case BPF_TRACE_FSESSION:
> + case BPF_TRACE_FENTRY_MULTI:
> + case BPF_TRACE_FEXIT_MULTI:
The new multi types are added to this switch, but earlier in the same
function bpf_check_attach_target() there is a check that prevents
BPF_PROG_TYPE_EXT from targeting fentry/fexit/fsession programs:
kernel/bpf/verifier.c:bpf_check_attach_target() {
...
if (tgt_prog->type == BPF_PROG_TYPE_TRACING &&
prog_extension &&
(tgt_prog->expected_attach_type == BPF_TRACE_FENTRY ||
tgt_prog->expected_attach_type == BPF_TRACE_FEXIT ||
tgt_prog->expected_attach_type == BPF_TRACE_FSESSION)) {
bpf_log(log, "Cannot extend fentry/fexit/fsession\n");
return -EINVAL;
}
...
}
Should BPF_TRACE_FENTRY_MULTI and BPF_TRACE_FEXIT_MULTI be included
in that check as well? The comment above it explains that extending
fentry/fexit programs is blocked to prevent
fentry->extension->fentry->extension call chains. Multi programs map
to BPF_TRAMP_FENTRY/BPF_TRAMP_FEXIT in bpf_attach_type_to_tramp(),
so the same concern would apply.
> @@ -25202,7 +25212,17 @@ int bpf_check_attach_target(struct bpf_verifier_log
> *log,
[ ... ]
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/22692622038
