]> git.ipfire.org Git - thirdparty/kernel/linux.git/commit
bpf: Dissociate struct_ops program with map if map_update fails
authorAmery Hung <ameryhung@gmail.com>
Fri, 17 Apr 2026 17:49:00 +0000 (10:49 -0700)
committerAlexei Starovoitov <ast@kernel.org>
Fri, 17 Apr 2026 19:04:14 +0000 (12:04 -0700)
commitf75aeb2de89127052975b1bfade88ac87f164f4a
treebe9421cf81fc95b5df96863c30ada332c1e05a2a
parent2845989f2ebaf7848e4eccf9a779daf3156ea0a5
bpf: Dissociate struct_ops program with map if map_update fails

Currently, when bpf_struct_ops_map_update_elem() fails, the programs'
st_ops_assoc will remain set. They may become dangling pointers if the
map is freed later, but they will never be dereferenced since the
struct_ops attachment did not succeed. However, if one of the programs
is subsequently attached as part of another struct_ops map, its
st_ops_assoc will be poisoned even though its old st_ops_assoc was stale
from a failed attachment.

Fix the spurious poisoned st_ops_assoc by dissociating struct_ops
programs with a map if the attachment fails. Move
bpf_prog_assoc_struct_ops() to after *plink++ to make sure
bpf_prog_disassoc_struct_ops() will not miss a program when iterating
st_map->links.

Note that, dissociating a program from a map requires some attention as
it must not reset a poisoned st_ops_assoc or a st_ops_assoc pointing to
another map. The former is already guarded in
bpf_prog_disassoc_struct_ops(). The latter also will not happen since
st_ops_assoc of programs in st_map->links are set by
bpf_prog_assoc_struct_ops(), which can only be poisoned or pointing to
the current map.

Signed-off-by: Amery Hung <ameryhung@gmail.com>
Link: https://lore.kernel.org/r/20260417174900.2895486-1-ameryhung@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
kernel/bpf/bpf_struct_ops.c