Re: [PATCH bpf-next 07/13] bpf: Add tracing_multi link info support for bpf progs

On 9/8/26 23:17, [email protected] wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [Medium] Out-of-bounds Read / Uninitialized Memory Leak in sym_name_trim_prefix()
> - [Medium] UAPI Anti-Pattern: Usage of C bitfields in UAPI headers
> --
> 
> --- Patch [7]: [PATCH bpf-next 07/13] bpf: Add tracing_multi link info support for bpf progs ---
> commit 65386c192a0d673092c95f3f31578ae7c4d19498
> Author: Leon Hwang <[email protected]>
> Subject: bpf: Add tracing_multi link info support for bpf progs
> 
> This commit adds tracing_multi link info support for BPF programs. It
> updates the bpf_link_info structure and extends bpftool to show function
> BTF IDs and program IDs.
> 
>> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
>> index 6fa93a6ff54f2..e0c8ea5ed2c8f 100644
>> --- a/include/uapi/linux/bpf.h
>> +++ b/include/uapi/linux/bpf.h
>> @@ -6890,10 +6890,12 @@ struct bpf_link_info {
>>  			__u32 attach_type;
>>  			__u32 count; /* in/out: tracing_multi target count */
>>  			__u32 btf_obj_id;
>> -			__u32 :32;
>> +			__u32 tgt_progs:1;
>> +			__u32 :31;
> 
> [Severity: Medium]
> Could this cause endianness issues since C bitfield layout is
> implementation-defined?
> 
> The established Linux UAPI standard is to use a __u32 flags field with
> bitmask macros instead of C bitfields to ensure portability across
> architectures and cross-platform tools. (This also applies to the mirrored
> header in tools/include/uapi/linux/bpf.h).
> 

Correct.

Will use the bit mask style by changing '__u32 :32' to '__u32 flags' and
adding BPF_F_TRACING_MULTI_TGT_PROGS.

> [ ... ]
> 
>> diff --git a/tools/bpf/bpftool/link.c b/tools/bpf/bpftool/link.c
>> index 088d1d206065f..d5c5ec433350b 100644
>> --- a/tools/bpf/bpftool/link.c
>> +++ b/tools/bpf/bpftool/link.c
> [ ... ]
>> +#define BPF_PROG_PREFIX		"bpf_prog_"
>> +#define BPF_PROG_PREFIX_LEN	(sizeof(BPF_PROG_PREFIX) - 1)
>> +
>> +static const char *
>> +sym_name_trim_prefix(struct kernel_sym *sym, bool is_prog)
>> +{
>> +	int prefix_len;
>> +
>> +	if (!is_prog)
>> +		return sym->name;
>> +
>> +	/* Ref kernel/bpf/core.c::bpf_prog_ksym_set_name() */
>> +	prefix_len  = BPF_PROG_PREFIX_LEN;
>> +	prefix_len += BPF_TAG_SIZE * 2;
>> +	prefix_len += 1;			/* skip the '_' */
>> +	return sym->name + prefix_len;
> 
> [Severity: Medium]
> Does this code read past the null terminator for unnamed BPF programs?
> 
> When processing an unnamed BPF program (e.g., exported in kallsyms as
> bpf_prog_9a7f9e3ab6f138ab), the sym->name buffer contains exactly 25
> characters. Here, prefix_len is calculated as 26 (9 + 16 + 1).
> 
> This offset advances the pointer past the null terminator into
> uninitialized heap memory, which is then passed to the JSON string writer
> when calling jsonw_string_field() later in show_tracing_multi_json().
> 

Correct.

According to bpf_prog_ksym_set_name(), will check "sym->name[prefix_len]
!= '\0'" before "+= 1".

Thanks,
Leon