Commit f75aeb2
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>1 parent 2845989 commit f75aeb2
1 file changed
Lines changed: 4 additions & 3 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
811 | 811 | | |
812 | 812 | | |
813 | 813 | | |
814 | | - | |
815 | | - | |
816 | | - | |
817 | 814 | | |
818 | 815 | | |
819 | 816 | | |
| |||
824 | 821 | | |
825 | 822 | | |
826 | 823 | | |
| 824 | + | |
| 825 | + | |
| 826 | + | |
827 | 827 | | |
828 | 828 | | |
829 | 829 | | |
| |||
906 | 906 | | |
907 | 907 | | |
908 | 908 | | |
| 909 | + | |
909 | 910 | | |
910 | 911 | | |
911 | 912 | | |
| |||
0 commit comments