On Fri, 2026-07-10 at 15:25 +0800, sun jian wrote: > On Fri, Jul 10, 2026 at 2:23 PM Eduard Zingerman <[email protected]> wrote: > > > > On Fri, 2026-07-10 at 13:52 +0800, sun jian wrote: > > > > [...] > > > > > There is an observable effect on the target bpf base. I tested it with a > > > temporary raw_tp writable test_run reproducer, not part of the series. It > > > attaches a raw_tp writable program to bpf_test_finish and triggers it > > > through BPF_PROG_TEST_RUN. The program does: > > > > > > r6 = *(u64 *)(r1 + 0) > > > r6 += -8 > > > *(u64 *)(r6 + 0) = 0 > > > > > > With KASAN enabled and the BPF JIT disabled, on the bpf base without the > > > verifier fix, the program loads, attaches, executes, and KASAN reports: > > > > Could you please identify why the behaviour differs between bpf and > > bpf-next? > > I checked the current bpf-next, but I could not reproduce the difference. > > Both the public cgit page and my local bpf-next/master and bpf-next/for-next > point to: > a4553044d1af ("Merge branch > 'bpf-bound-rdonly-rdwr_buf_size-kfunc-return-size'") > > I tested that tree with only the selftest patch applied. The staged diff > only contains: > > tools/testing/selftests/bpf/prog_tests/raw_tp_writable_reject_nbd_invalid.c > tools/testing/selftests/bpf/progs/verifier_raw_tp_writable.c > > The negative const-offset case is still accepted at load time: > > #637/2 verifier_raw_tp_writable/raw_tracepoint_writable: reject > negative const offset:FAIL > run_subtest:FAIL:unexpected_load_success unexpected success: 0 > > and the verifier log only shows: > > processed 4 insns (limit 1000000) max_states_per_insn 0 total_states 0 > peak_states 0 mark_read 0
Here is the branch: https://github.com/eddyz87/bpf/tree/tp-buffer-negative-offset It is the current bpf-next HEAD [1] plus patches #1,2 and a revert of patch #1. I have KASAN enabled, the test is passing: #317 raw_tp_writable_reject_nbd_invalid:OK [1] c3d5ef291a2a ("selftests/bpf: Add test for scalar id on sign-extending stack fill") > The current __check_buffer_access() in that tree still only rejects a > negative instruction offset and a non-constant var_off. It does not check > the folded effective offset, so this case still has off=0 and var_off=-8 and > is accepted. > > So, at least on a4553044d1af, I do not see bpf-next rejecting this case. If > you have a bpf-next commit or verifier log where this case is rejected, I'd > be glad to take a look and reconcile; I may well be missing something in my > setup. > > Thanks, > Sun Jian > > > > [...]
