On Thu, Jun 23, 2016 at 10:07:27PM +0200, Daniel Borkmann wrote: > On 06/23/2016 06:54 PM, Martin KaFai Lau wrote: > >On Thu, Jun 23, 2016 at 11:53:50AM +0200, Daniel Borkmann wrote: > >>>diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c > >>>index 668e079..68753e0 100644 > >>>--- a/kernel/bpf/verifier.c > >>>+++ b/kernel/bpf/verifier.c > >>>@@ -1062,6 +1062,10 @@ static int check_map_func_compatibility(struct bpf_map *map, int func_id) > >>> if (func_id != BPF_FUNC_get_stackid) > >>> goto error; > >>> break; > >>>+ case BPF_MAP_TYPE_CGROUP_ARRAY: > >>>+ if (func_id != BPF_FUNC_skb_in_cgroup) > >>>+ goto error; > >>>+ break; > >> > >>I think the BPF_MAP_TYPE_CGROUP_ARRAY case should have been fist here in > >>patch 2/4, but with unconditional goto error. And this one only adds the > >>'func_id != BPF_FUNC_skb_in_cgroup' test. > >I am not sure I understand. Can you elaborate? I am probably missing > >something here. > > If someone backports patch 2/4 as-is, but for some reason not 3/4, then you > could craft a program that calls f.e. bpf_map_update_elem() on a cgroup array > and would thus cause a NULL pointer deref, since verifier doesn't prevent it. > I'm just trying to say that it would probably make sense to add the above 'case > BPF_MAP_TYPE_CGROUP_ARRAY:' with an unconditional 'goto error' in patch 2/4 > and extend upon it in patch 3/4 so result looks like here, so that the patches > are fine/complete each as stand-alone. I failed to connect some points in your last comment. Thanks for explaining. Make sense. I will spin v3. -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
