All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Florian Lehner" <dev@der-flo.net>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next 1/2 v3] bpf: Add LINK_DETACH support for perf link
Date: Fri, 01 May 2026 16:59:09 +0000	[thread overview]
Message-ID: <20260501165909.EABE1C2BCC6@smtp.kernel.org> (raw)
In-Reply-To: <20260501160901.224134-2-dev@der-flo.net>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Concurrent execution of BPF_LINK_DETACH and BPF_OBJ_GET_INFO_BY_FD (or /proc/pid/fdinfo reads) causes a NULL pointer dereference on event->prog.
--

commit 738bb49794369ff2bcc7c3d461300bd57e714cf5
Author: Florian Lehner <dev@der-flo.net>

bpf: Add LINK_DETACH support for perf link

This commit implements the .detach operation for bpf_perf_link, allowing
BPF_LINK_DETACH to release the perf event without destroying the link object.

> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> --- a/kernel/bpf/syscall.c
> +++ b/kernel/bpf/syscall.c

[ ... ]

> @@ -4095,22 +4117,42 @@ static int bpf_perf_link_fill_link_info(const struct bpf_link *link,
>  {
>  	struct bpf_perf_link *perf_link;
>  	const struct perf_event *event;
> +	struct file *perf_file;
> +	int ret;
>  
>  	perf_link = container_of(link, struct bpf_perf_link, link);
> -	event = perf_get_event(perf_link->perf_file);
> -	if (IS_ERR(event))
> +
> +	mutex_lock(&bpf_perf_link_mutex);
> +	perf_file = perf_link->perf_file;
> +	if (perf_file)
> +		get_file(perf_file);
> +	mutex_unlock(&bpf_perf_link_mutex);
> +
> +	if (!perf_file)
> +		return 0;
> +
> +	event = perf_get_event(perf_file);
> +	if (IS_ERR(event)) {
> +		fput(perf_file);
>  		return PTR_ERR(event);
> +	}
>  
>  	switch (event->prog->type) {

Can this result in a NULL pointer dereference on event->prog?

If a concurrent BPF_LINK_DETACH triggers bpf_perf_link_release(), it sets
perf_link->perf_file = NULL under the mutex, drops the mutex, and then calls
perf_event_free_bpf_prog(event).

If perf_event_free_bpf_prog() clears event->prog right after we drop the
mutex here but before we evaluate the switch statement, evaluating
event->prog->type could panic.

Would it be safer to use link->prog->type instead? The program reference in
link->prog is pinned for the lifetime of the link object.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260501160901.224134-1-dev@der-flo.net?part=1

  parent reply	other threads:[~2026-05-01 16:59 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-01 16:08 [PATCH bpf-next 0/2 v3] bpf: Add LINK_DETACH for perf links Florian Lehner
2026-05-01 16:09 ` [PATCH bpf-next 1/2 v3] bpf: Add LINK_DETACH support for perf link Florian Lehner
2026-05-01 16:52   ` bot+bpf-ci
2026-05-01 16:59   ` sashiko-bot [this message]
2026-05-01 16:09 ` [PATCH bpf-next 2/2 v3] selftests/bpf: Test LINK_DETACH " Florian Lehner
2026-05-01 17:11   ` sashiko-bot
2026-05-03 13:14   ` Jiri Olsa

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=20260501165909.EABE1C2BCC6@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=dev@der-flo.net \
    --cc=sashiko@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.