From: sashiko-bot@kernel.org
To: "Martin KaFai Lau" <martin.lau@linux.dev>
Cc: bpf@vger.kernel.org
Subject: Re: [RFC PATCH bpf-next 04/12] bpf: Remove unnecessary prog_list_prog() check
Date: Tue, 19 May 2026 22:49:59 +0000 [thread overview]
Message-ID: <20260519225000.EF4F81F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260519215841.2984970-5-martin.lau@linux.dev>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [Critical] replace_effective_prog() incorrectly uses absolute indexing into the bpf_prog_array, failing to account for dummy programs left by failed detach operations.
--
commit 77c3b439749a112ce3763d2ced5be03b93639458
Author: Martin KaFai Lau <martin.lau@kernel.org>
bpf: Remove unnecessary prog_list_prog() check
This patch removes the !prog_list_prog(pl) checks in replace_effective_prog()
and purge_effective_progs(). It cleans up conditions that are not expected
to happen, serving as preparation for attaching struct_ops to cgroups.
> diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c
> index 876f6a81a9b61..71591f6dc4581 100644
> --- a/kernel/bpf/cgroup.c
> +++ b/kernel/bpf/cgroup.c
> @@ -946,8 +946,6 @@ static void replace_effective_prog(struct cgroup *cgrp,
>
> head = &cg->bpf.progs[atype];
> hlist_for_each_entry(pl, head, node) {
> - if (!prog_list_prog(pl))
> - continue;
> if (pl->link == link)
> goto found;
> pos++;
[Severity: Critical]
This is a pre-existing issue, but does using pos as an absolute index here
cause problems if a prior detach operation failed?
When __cgroup_bpf_detach() fails to allocate a new array via
update_effective_progs(), it falls back to purge_effective_progs().
This fallback uses bpf_prog_array_delete_safe_at() to replace the detached
program with a dummy program in the active array, and then removes the
detached program's node from the cgroup's hlist.
Later in replace_effective_prog(), we iterate the hlist to calculate pos.
Because the detached program is no longer in the hlist, pos represents the
logical index of the program (skipping the dummy program).
However, looking at what happens immediately after the found label:
found:
BUG_ON(!cg);
progs = rcu_dereference_protected(
desc->bpf.effective[atype],
lockdep_is_held(&cgroup_mutex));
item = &progs->items[pos];
WRITE_ONCE(item->prog, link->link.prog);
The code uses pos as an absolute index into the array (progs->items[pos]).
Because the array still contains the dummy program, the logical index
calculated from the hlist no longer matches the absolute index in the array.
Could this cause the wrong item to be overwritten, leaving the original
program pointer in the active effective array? Since the caller (like
__cgroup_bpf_replace()) drops the reference count of the replaced program,
would this directly lead to a use-after-free when the cgroup BPF hooks are
subsequently executed?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260519215841.2984970-1-martin.lau@linux.dev?part=4
next prev parent reply other threads:[~2026-05-19 22:50 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-19 21:58 [RFC PATCH bpf-next 00/12] bpf: A common way to attach struct_ops to a cgroup Martin KaFai Lau
2026-05-19 21:58 ` [RFC PATCH bpf-next 01/12] bpf: Remove __rcu tagging in st_link->map Martin KaFai Lau
2026-05-19 21:58 ` [RFC PATCH bpf-next 02/12] bpf: Make struct_ops tasks_rcu grace period optional Martin KaFai Lau
2026-05-19 22:54 ` sashiko-bot
2026-05-20 0:25 ` Martin KaFai Lau
2026-05-19 21:58 ` [RFC PATCH bpf-next 03/12] bpf: Add bpf_struct_ops accessor helpers Martin KaFai Lau
2026-05-19 22:25 ` sashiko-bot
2026-05-19 21:58 ` [RFC PATCH bpf-next 04/12] bpf: Remove unnecessary prog_list_prog() check Martin KaFai Lau
2026-05-19 22:49 ` sashiko-bot [this message]
2026-05-19 21:58 ` [RFC PATCH bpf-next 05/12] bpf: Replace prog_list_prog() check with direct pl->prog and pl->link check Martin KaFai Lau
2026-05-19 21:58 ` [RFC PATCH bpf-next 06/12] bpf: Add prog_list_init_item(), prog_list_replace_item(), and prog_list_id() Martin KaFai Lau
2026-05-19 21:58 ` [RFC PATCH bpf-next 07/12] bpf: Move LSM trampoline unlink into bpf_cgroup_link_auto_detach() Martin KaFai Lau
2026-05-19 21:58 ` [RFC PATCH bpf-next 08/12] bpf: Add a few bpf_cgroup_array_* helper functions Martin KaFai Lau
2026-05-19 22:45 ` sashiko-bot
2026-05-19 22:50 ` Martin KaFai Lau
2026-05-19 21:58 ` [RFC PATCH bpf-next 09/12] bpf: Add infrastructure to support attaching struct_ops to cgroups Martin KaFai Lau
2026-05-19 22:50 ` sashiko-bot
2026-05-19 23:56 ` Martin KaFai Lau
2026-05-19 21:58 ` [RFC PATCH bpf-next 10/12] bpf: tcp: Support selected sock_ops callbacks as struct_ops Martin KaFai Lau
2026-05-19 21:58 ` [RFC PATCH bpf-next 11/12] libbpf: Support attaching struct_ops to a cgroup Martin KaFai Lau
2026-05-19 21:58 ` [RFC PATCH bpf-next 12/12] selftests/bpf: Test " Martin KaFai Lau
2026-05-19 23:03 ` sashiko-bot
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=20260519225000.EF4F81F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=martin.lau@linux.dev \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox