bpf: fix wrong helper enablement in cgroup local storage
Subsystems (4)
Daniel Borkmann
maintainerPATCH 1/1 bpf: fix wrong helper enablement in cgroup local storage
Commit cd3394317653 ("bpf: introduce the bpf_get_local_storage() helper function") enabled the bpf_get_local_storage() helper also for BPF program types where it does not make sense to use them.
They have been added both in sk_skb_func_proto() and sk_msg_func_proto() even though both program types are not invoked in combination with cgroups, and neither through BPF_PROG_RUN_ARRAY(). In the latter the bpf_cgroup_storage_set() is set shortly before BPF program invocation.
Later, the helper bpf_get_local_storage() retrieves this prior set up per-cpu pointer and hands the buffer to the BPF program. The map argument in there solely retrieves the enum bpf_cgroup_storage_type from a local storage map associated with the program and based on the type returns either the global or per-cpu storage. However, there is no specific association between the program's map and the actual content in bpf_cgroup_storage[].
Meaning, any BPF program that would have been properly run from the cgroup side through BPF_PROG_RUN_ARRAY() where bpf_cgroup_storage_set() was performed, and that is later unloaded such that prog / maps are teared down will cause a use after free if that pointer is retrieved from programs that are not run through BPF_PROG_RUN_ARRAY() but have the cgroup local storage helper enabled in their func proto.
Lets just remove it from the two sock_map program types to fix it. Auditing through the types where this helper is enabled, it appears that these are the only ones where it was mistakenly allowed.
--- net/core/filter.c | 4 ---- 1 file changed, 4 deletions(-)
net/core/filter.c +0 -4
@@ -5264,8 +5264,6 @@ sk_msg_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)return &bpf_msg_pull_data_proto;case BPF_FUNC_msg_push_data:return &bpf_msg_push_data_proto; -case BPF_FUNC_get_local_storage: -return &bpf_get_local_storage_proto;default :return bpf_base_func_proto (func_id); }
@@ -5296,8 +5294,6 @@ sk_skb_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)return &bpf_sk_redirect_map_proto;case BPF_FUNC_sk_redirect_hash:return &bpf_sk_redirect_hash_proto; -case BPF_FUNC_get_local_storage: -return &bpf_get_local_storage_proto;#ifdef CONFIG_INET case BPF_FUNC_sk_lookup_tcp:return &bpf_sk_lookup_tcp_proto;
Signature · 1 line
2.9.5
Quoted 24 lines · Daniel Borkmann
Commit
cd3394317653("bpf: introduce thebpf_get_local_storage()helper function") enabled thebpf_get_local_storage()helper also for BPF program types where it does not make sense to use them.They have been added both in
sk_skb_func_proto()andsk_msg_func_proto()even though both program types are not invoked in combination with cgroups, and neither throughBPF_PROG_RUN_ARRAY(). In the latter thebpf_cgroup_storage_set()is set shortly before BPF program invocation.Later, the helper
bpf_get_local_storage()retrieves this prior set up per-cpu pointer and hands the buffer to the BPF program. The map argument in there solely retrieves the enumbpf_cgroup_storage_typefrom a local storage map associated with the program and based on the type returns either the global or per-cpu storage. However, there is no specific association between the program's map and the actual content in bpf_cgroup_storage[].Meaning, any BPF program that would have been properly run from the cgroup side through
BPF_PROG_RUN_ARRAY()wherebpf_cgroup_storage_set()was performed, and that is later unloaded such that prog / maps are teared down will cause a use after free if that pointer is retrieved from programs that are not run throughBPF_PROG_RUN_ARRAY()but have the cgroup local storage helper enabled in their func proto.
Quoted 8 lines
Lets just remove it from the two
sock_mapprogram types to fix it. Auditing through the types where this helper is enabled, it appears that these are the only ones where it was mistakenly allowed.Fixes cd3394317653 ("bpf: introduce the bpf_get_local_storage() helper function")Signed-off-by Daniel Borkmann <[email protected]>Cc Roman Gushchin <[email protected]>Acked-by John Fastabend <[email protected]>
Thanks, Daniel!
Alexei Starovoitov
AppliedQuoted 29 lines · Roman Gushchin
Quoted 28 lines · Daniel Borkmann
Commit
cd3394317653("bpf: introduce thebpf_get_local_storage()helper function") enabled thebpf_get_local_storage()helper also for BPF program types where it does not make sense to use them.They have been added both in
sk_skb_func_proto()andsk_msg_func_proto()even though both program types are not invoked in combination with cgroups, and neither throughBPF_PROG_RUN_ARRAY(). In the latter thebpf_cgroup_storage_set()is set shortly before BPF program invocation.Later, the helper
bpf_get_local_storage()retrieves this prior set up per-cpu pointer and hands the buffer to the BPF program. The map argument in there solely retrieves the enumbpf_cgroup_storage_typefrom a local storage map associated with the program and based on the type returns either the global or per-cpu storage. However, there is no specific association between the program's map and the actual content in bpf_cgroup_storage[].Meaning, any BPF program that would have been properly run from the cgroup side through
BPF_PROG_RUN_ARRAY()wherebpf_cgroup_storage_set()was performed, and that is later unloaded such that prog / maps are teared down will cause a use after free if that pointer is retrieved from programs that are not run throughBPF_PROG_RUN_ARRAY()but have the cgroup local storage helper enabled in their func proto.Lets just remove it from the two
sock_mapprogram types to fix it. Auditing through the types where this helper is enabled, it appears that these are the only ones where it was mistakenly allowed.
Quoted 7 lines
Quoted 4 lines
Fixes cd3394317653 ("bpf: introduce the bpf_get_local_storage() helper function")Signed-off-by Daniel Borkmann <[email protected]>Cc Roman Gushchin <[email protected]>Acked-by John Fastabend <[email protected]>Acked-by Roman Gushchin <[email protected]>
Applied, Thanks