Re: [PATCH bpf-next v7 2/3] bpf: Fix s16 truncation for large bpf-to-bpf call offsets

On 4/22/26 4:46 AM, [email protected] wrote:
> Sashiko AI review found 1 potential issue(s):
> - [Medium] bpftool's control-flow graph generator (cfg.c) was not updated to reflect the `insn->off` and `insn->imm` swap for BPF_PSEUDO_CALL, which will break visual dumps.
> --
> 
> commit bbf026d16d77a3e1debc60ea3a7b2fef7d7def5e
> Author: Yazhou Tang <[email protected]>
> 
> bpf: Fix s16 truncation for large bpf-to-bpf call offsets
> 
> This commit fixes an s16 truncation issue for large bpf-to-bpf call
> offsets when JIT is disabled or falls back to the interpreter.
> It does this by using the off field to store the interpreter function
> index and the imm field to pass the original offset.
> The related dumper code was also updated to adapt to this change.
> 
>> diff --git a/kernel/bpf/fixups.c b/kernel/bpf/fixups.c
>> index 300e4e2519318..8947ef74f6a88 100644
>> --- a/kernel/bpf/fixups.c
>> +++ b/kernel/bpf/fixups.c
>> @@ -1250,9 +1250,9 @@ static int jit_subprogs(struct bpf_verifier_env *env)
>>   		}
>>   		if (!bpf_pseudo_call(insn))
>>   			continue;
>> -		insn->off = env->insn_aux_data[i].call_imm;
>> -		subprog = bpf_find_subprog(env, i + insn->off + 1);
>> -		insn->imm = subprog;
>> +		insn->imm = env->insn_aux_data[i].call_imm;
>> +		subprog = bpf_find_subprog(env, i + insn->imm + 1);
>> +		insn->off = subprog;
>>   	}
> 
> Since insn->imm and insn->off are now swapped for exported translated
> programs, should tools/bpf/bpftool/cfg.c also be updated?
> 
> It looks like cfg_partition_funcs() currently relies on cur->off to
> calculate the target subprogram start when generating the control-flow
> graph:
> 
> tools/bpf/bpftool/cfg.c:cfg_partition_funcs() {
>          ...
> 	for (; cur < end; cur++) {
> 		if (cur->code != (BPF_JMP | BPF_CALL))
> 			continue;
> 		if (cur->src_reg != BPF_PSEUDO_CALL)
> 			continue;
> 		func = cfg_append_func(cfg, cur + cur->off + 1);
> 		if (!func)
> 			return true;
> 	}
>          ...
> }
> 
> Because cur->off now holds the subprogram index instead of the jump offset,
> could this point to the wrong instruction and cause a corrupted graph or
> out-of-bounds memory access during bpftool prog dump xlated visual?
> 

This is a valid point. I will fix this issue in next version.