All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Leon Hwang" <leon.hwang@linux.dev>, bpf@vger.kernel.org
Cc: linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH bpf-next 5/9] libbpf: Add log_opts support for BPF_TRACE_ITER
Date: Mon, 09 Nov 2026 14:36:38 +0000	[thread overview]
Message-ID: <sashiko-outbox-205120@kernel.org> (raw)
In-Reply-To: <20261109140816.5196-6-leon.hwang@linux.dev>

Thank you for your contribution! Sashiko AI review found 3 potential
issues to consider:
- [Low] libbpf: missing OPTS_ZEROED() check for BPF_TRACE_ITER in
  bpf_link_create()
- [Low] libbpf: unreachable iter.len check in bpf_link_create()
- [Low] libbpf: deprecated iter_info fields used in
  bpf_program__attach_iter()
--

commit 254d03820df80f0d29b270cec3be5cafe9178fe6
Author: Leon Hwang <leon.hwang@linux.dev>

libbpf: Add log_opts support for BPF_TRACE_ITER

This commit adds iter.info and iter.len to struct bpf_link_create_opts so
that BPF_TRACE_ITER link creation can pass iterator parameters alongside
log_opts, while keeping the legacy iter_info and iter_info_len fields for
callers that do not use log_opts.

> diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
> index 38dcb31e8c0ed..174a8bfaf6638 100644
> --- a/tools/lib/bpf/bpf.c
> +++ b/tools/lib/bpf/bpf.c
> @@ -808,11 +808,6 @@ int bpf_link_create(int prog_fd, int target_fd,
>  	if (iter_info_len && attach_type != BPF_TRACE_ITER)
>  		return libbpf_err(-EINVAL);
>  
> -	if (iter_info_len)
> -		iter_info = OPTS_GET(opts, iter_info, (void *)0);
> -	else
> -		log_opts = OPTS_GET(opts, log_opts, (void *)0);
> -
>  	/* validate we don't have unexpected combinations of non-zero fields */
>  	if (iter_info_len || target_btf_id) {
>  		if (iter_info_len && target_btf_id)
> @@ -821,6 +816,16 @@ int bpf_link_create(int prog_fd, int target_fd,
>  			return libbpf_err(-EINVAL);
>  	}
>  
> +	if (iter_info_len) {
> +		if (OPTS_GET(opts, iter.len, 0))
> +			return libbpf_err(-EINVAL);

[Severity: Low]
Can OPTS_GET(opts, iter.len, 0) ever be non-zero here?  When iter_info_len
is set, the preceding if (iter_info_len || target_btf_id) block has already
verified OPTS_ZEROED(opts, target_btf_id), which rejects any non-zero bytes
in the union following target_btf_id, including opts->iter.len.

> +		iter_info = OPTS_GET(opts, iter_info, (void *)0);
> +	} else {
> +		log_opts = OPTS_GET(opts, log_opts, (void *)0);
> +		iter_info = OPTS_GET(opts, iter.info, (void *)0);
> +		iter_info_len = OPTS_GET(opts, iter.len, 0);
> +	}

[Severity: Low]
Should bpf_program__attach_iter() also be updated to populate
link_create_opts.iter.info and link_create_opts.iter.len instead of the
deprecated iter_info and iter_info_len fields?

tools/lib/bpf/libbpf.c:bpf_program__attach_iter() {
    ...
	link_create_opts.iter_info = OPTS_GET(opts, link_info, (void *)0);
	link_create_opts.iter_info_len = OPTS_GET(opts, link_info_len, 0);
    ...
}

Because iter_info shares a union with log_opts, calling
bpf_program__attach_iter() with link_info != NULL and link_info_len == 0
causes bpf_link_create() to take the else branch above and dereference the
union bpf_iter_link_info pointer as struct bpf_log_opts *log_opts in
__sys_bpf_fd().

[ ... ]

> diff --git a/tools/lib/bpf/bpf.h b/tools/lib/bpf/bpf.h
> index fe3b7fd8512bd..2ac143fd1102e 100644
> --- a/tools/lib/bpf/bpf.h
> +++ b/tools/lib/bpf/bpf.h

[ ... ]

> @@ -478,6 +482,10 @@ struct bpf_link_create_opts {
>  			const __u64 *cookies;
>  			__u32 cnt;
>  		} tracing_multi;
> +		struct {
> +			union bpf_iter_link_info *info;
> +			__u32 len;
> +		} iter;
>  	};
>  	size_t :0;
>  };

[Severity: Low]
Does case BPF_TRACE_ITER in bpf_link_create() miss an OPTS_ZEROED(opts,
iter) check?

tools/lib/bpf/bpf.c:bpf_link_create() {
    ...
	switch (attach_type) {
	case BPF_TRACE_ITER:
		attr.link_create.iter_info = ptr_to_u64(iter_info);
		attr.link_create.iter_info_len = iter_info_len;
		break;
    ...
}

When opts->iter is used (so iter_info_len and target_btf_id are 0),
trailing bytes in the anonymous union after opts->iter overlapping larger
members such as uprobe_multi are not checked for zero, unlike all other
union members in the switch statement.  Also, opts->iter.info and
opts->iter.len are read in the !iter_info_len branch even when attach_type
is not BPF_TRACE_ITER.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261109140816.5196-1-leon.hwang@linux.dev?part=5

  reply	other threads:[~2026-11-09 14:36 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-09 14:08 [PATCH bpf-next 0/9] bpf: Add log support for tracing link_create Leon Hwang
2026-11-09 14:08 ` [PATCH bpf-next 1/9] " Leon Hwang
2026-11-09 14:47   ` bot+bpf-ci
2026-11-11 15:31     ` Leon Hwang
2026-11-09 14:08 ` [PATCH bpf-next 2/9] bpf: Add log support for tracing_multi link_create Leon Hwang
2026-11-09 14:08 ` [PATCH bpf-next 3/9] bpf: Add log support for iter link_create Leon Hwang
2026-11-09 14:22   ` sashiko-bot
2026-11-11 15:32     ` Leon Hwang
2026-11-09 14:08 ` [PATCH bpf-next 4/9] bpf: Add log support for cgroup prog link_create Leon Hwang
2026-11-09 14:47   ` bot+bpf-ci
2026-11-11 15:32     ` Leon Hwang
2026-11-09 14:08 ` [PATCH bpf-next 5/9] libbpf: Add log_opts support for BPF_TRACE_ITER Leon Hwang
2026-11-09 14:36   ` sashiko-bot [this message]
2026-11-11 15:33     ` Leon Hwang
2026-11-09 14:47   ` bot+bpf-ci
2026-11-11 15:32     ` Leon Hwang
2026-11-09 14:08 ` [PATCH bpf-next 6/9] selftests/bpf: Verify tracing link_create logs Leon Hwang
2026-11-09 14:47   ` bot+bpf-ci
2026-11-11 15:34     ` Leon Hwang
2026-11-09 14:08 ` [PATCH bpf-next 7/9] selftests/bpf: Verify tracing_multi " Leon Hwang
2026-11-09 14:08 ` [PATCH bpf-next 8/9] selftests/bpf: Verify iter " Leon Hwang
2026-11-09 14:08 ` [PATCH bpf-next 9/9] selftests/bpf: Verify cgroup prog " Leon Hwang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=sashiko-outbox-205120@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=leon.hwang@linux.dev \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.