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

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).

[ ... ]

> 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().

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=7