]> git.ipfire.org Git - thirdparty/kernel/linux.git/commit
bpf: Fix effective prog array index with BPF_F_PREORDER
authorAmery Hung <ameryhung@gmail.com>
Fri, 19 Jun 2026 06:35:19 +0000 (23:35 -0700)
committerAlexei Starovoitov <ast@kernel.org>
Mon, 22 Jun 2026 01:10:04 +0000 (18:10 -0700)
commitf08aaee3152d0dfc578b3f2586932d82062701dd
tree66460791b15dd14f6d54223dc800767b38842f5a
parent8405c4626460503027461652f96d8bb10c2a9173
bpf: Fix effective prog array index with BPF_F_PREORDER

replace_effective_prog() and purge_effective_progs() located the slot in
the effective array by walking the program hlist and counting entries
linearly. That count does not match the array layout: compute_effective_
progs() places BPF_F_PREORDER programs at the front (ancestor cgroup
first, attach order within a cgroup) and the rest after them (descendant
cgroup first). So when a preorder program is present, the linear hlist
position no longer equals the program's index in the effective array.

For replace_effective_prog() (bpf_link_update()) this overwrote the
wrong slot, corrupting the effective order. For purge_effective_progs(),
it could dummy out a slot belonging to a different program and leave the
detached program in the array while bpf_prog_put() drops its reference,
i.e. a use-after-free.

Fix both by replaying compute_effective_progs()'s placement (including
the per-cgroup preorder reversal) in a shared effective_prog_pos()
helper. Identify the entry by its struct bpf_prog_list pointer rather
than by (prog, link) value, so the lookup resolves to exactly the
attachment the syscall selected even when the same bpf_prog is attached
to several cgroups in the hierarchy.

Fixes: 4b82b181a26c ("bpf: Allow pre-ordering for bpf cgroup progs")
Signed-off-by: Amery Hung <ameryhung@gmail.com>
Acked-by: Yonghong Song <yonghong.song@linux.dev>
Link: https://lore.kernel.org/r/20260619063520.2690547-2-ameryhung@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
kernel/bpf/cgroup.c