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
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
>
> [...]
