Re: [PATCH bpf-next v11 02/12] bpf: use the least significant byte for the nr_args in trampoline
From: bot+bpf-ci@kernel.org
Date: 2026-01-23 08:07:46
Also in:
bpf, lkml
quoted hunk ↗ jump to hunk
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c index 41bbed6418b5..b3f912ad18ba 100644 --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c
[ ... ]
quoted hunk ↗ jump to hunk
@@ -23779,12 +23781,13 @@ static int do_misc_fixups(struct bpf_verifier_env *env) eatype == BPF_MODIFY_RETURN) { /* Load nr_args from ctx - 8 */ insn_buf[0] = BPF_LDX_MEM(BPF_DW, BPF_REG_0, BPF_REG_1, -8); - insn_buf[1] = BPF_ALU64_IMM(BPF_LSH, BPF_REG_0, 3); + insn_buf[1] = BPF_ALU64_IMM(BPF_AND, BPF_REG_0, 0xFF); + insn_buf[2] = BPF_ALU64_IMM(BPF_LSH, BPF_REG_0, 3);
[ ... ]
- cnt = 6;
+ cnt = 7;
} else {
insn_buf[0] = BPF_MOV64_IMM(BPF_REG_0, -EOPNOTSUPP);
cnt = 1;
}
new_prog = bpf_patch_insn_data(env, i + delta, insn_buf, cnt);[ ... ]
delta += cnt - 1;
Note that the bpf_get_func_ret block above correctly updates delta after patching.
quoted hunk ↗ jump to hunk
@@ -23808,12 +23811,15 @@ static int do_misc_fixups(struct bpf_verifier_env *env) /* skip 'void *__data' in btf_trace_##name() and save to reg0 */ insn_buf[0] = BPF_MOV64_IMM(BPF_REG_0, nr_args - 1); + cnt = 1; } else { /* Load nr_args from ctx - 8 */ insn_buf[0] = BPF_LDX_MEM(BPF_DW, BPF_REG_0, BPF_REG_1, -8); + insn_buf[1] = BPF_ALU64_IMM(BPF_AND, BPF_REG_0, 0xFF); + cnt = 2; } - new_prog = bpf_patch_insn_data(env, i + delta, insn_buf, 1); + new_prog = bpf_patch_insn_data(env, i + delta, insn_buf, cnt); if (!new_prog) return -ENOMEM; env->prog = prog = new_prog; insn = new_prog->insnsi + i + delta; goto next_insn; }
Should there be a "delta += cnt - 1;" before assigning env->prog in this
bpf_get_func_arg_cnt block? When cnt is 2 (non-RAW_TP path), the program
grows by one instruction, but delta is not updated. This could cause
subsequent bpf_patch_insn_data() calls to use incorrect offsets.
The bpf_get_func_arg block at the beginning of this patch has:
delta += cnt - 1;
env->prog = prog = new_prog;
And the bpf_get_func_ret block similarly has delta updated. But this
bpf_get_func_arg_cnt block goes directly to env->prog assignment without
updating delta.
---
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/21278745581