1. 20 Mar, 2015 2 commits
    • Daniel Borkmann's avatar
      net: cls_bpf: fix auto generation of per list handles · d817b892
      Daniel Borkmann authored
      commit 3f2ab135 upstream.
      
      When creating a bpf classifier in tc with priority collisions and
      invoking automatic unique handle assignment, cls_bpf_grab_new_handle()
      will return a wrong handle id which in fact is non-unique. Usually
      altering of specific filters is being addressed over major id, but
      in case of collisions we result in a filter chain, where handle ids
      address individual cls_bpf_progs inside the classifier.
      
      Issue is, in cls_bpf_grab_new_handle() we probe for head->hgen handle
      in cls_bpf_get() and in case we found a free handle, we're supposed
      to use exactly head->hgen. In case of insufficient numbers of handles,
      we bail out later as handle id 0 is not allowed.
      
      Fixes: 7d1d65cb ("net: sched: cls_bpf: add BPF-based classifier")
      Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Acked-by: default avatarJiri Pirko <jiri@resnulli.us>
      Acked-by: default avatarAlexei Starovoitov <ast@plumgrid.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      d817b892
    • Daniel Borkmann's avatar
      net: cls_bpf: fix size mismatch on filter preparation · 709178a6
      Daniel Borkmann authored
      commit 7913ecf6 upstream.
      
      In cls_bpf_modify_existing(), we read out the number of filter blocks,
      do some sanity checks, allocate a block on that size, and copy over the
      BPF instruction blob from user space, then pass everything through the
      classic BPF checker prior to installation of the classifier.
      
      We should reject mismatches here, there are 2 scenarios: the number of
      filter blocks could be smaller than the provided instruction blob, so
      we do a partial copy of the BPF program, and thus the instructions will
      either be rejected from the verifier or a valid BPF program will be run;
      in the other case, we'll end up copying more than we're supposed to,
      and most likely the trailing garbage will be rejected by the verifier
      as well (i.e. we need to fit instruction pattern, ret {A,K} needs to be
      last instruction, load/stores must be correct, etc); in case not, we
      would leak memory when dumping back instruction patterns. The code should
      have only used nla_len() as Dave noted to avoid this from the beginning.
      Anyway, lets fix it by rejecting such load attempts.
      
      Fixes: 7d1d65cb ("net: sched: cls_bpf: add BPF-based classifier")
      Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Acked-by: default avatarJiri Pirko <jiri@resnulli.us>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      709178a6
  2. 18 Mar, 2015 38 commits