On 26/06/13 05:33PM, Nuoqi Gui wrote: > For gotox, CFG construction models the indirect-jump target set in > insn_aux_data->jt, but do_check() later follows targets from the runtime > PTR_TO_INSN register's own INSN_ARRAY map. If the same gotox can be > reached with PTR_TO_INSN values from different maps, do_check() can accept > a target outside the subprog that CFG allowed for the gotox instruction. > > On x86, that can transfer control into another subprog without a matching > BPF call frame and crash when the program is run.
Why only on x86? > Fix this by rejecting gotox map targets outside the current gotox subprog. > Add a regression test covering the two-map cross-subprog case. > > Validation: > > unpatched bpf-next 7bfb93e3475b with the new selftest: > bpf_gotox/check-cross-subprog-gotox-target: FAIL > cross_subprog_gotox_prog_load: actual 23 != expected -22 > __TEST_PROGS_RC__=1 > > patched bpf-next 7bfb93e3475b + this series: > bpf_gotox/check-cross-subprog-gotox-target: OK > ./test_progs -t bpf_gotox/check-cross-subprog-gotox-target > Summary: 1/1 PASSED, 0 SKIPPED, 0 FAILED > __TEST_PROGS_RC__=0 Why the second part mentions the call to ./test_progs, and the first doesn't? Why the test result goes before the test run? Is this "Validation" section even required? > v1 -> v2: > - Validate gotox runtime targets against the current subprog bounds instead > of scanning the CFG jump table. > - Fix the selftest expected error from -EACCES to -EINVAL. > > v1: > > https://lore.kernel.org/bpf/20260609-f01-02-gotox-bpf-next-v1-0-b441d63a1...@mails.tsinghua.edu.cn/ > > Signed-off-by: Nuoqi Gui <[email protected]> > --- > Nuoqi Gui (2): > bpf: Enforce gotox targets against subprog bounds > selftests/bpf: Add cross-subprog gotox target coverage > > kernel/bpf/verifier.c | 21 +++++++ > tools/testing/selftests/bpf/prog_tests/bpf_gotox.c | 73 > ++++++++++++++++++++++ > 2 files changed, 94 insertions(+) > --- > base-commit: 7bfb93e3475be9de894f1cecd3a727d3e1649b03 > change-id: 20260613-f01-02-gotox-bpf-next-v2-send-8c48c9357dde > > Best regards, > -- > Nuoqi Gui <[email protected]> >
