1. 26 Mar, 2018 34 commits
  2. 25 Mar, 2018 6 commits
    • David S. Miller's avatar
      Merge branch 'hv_netvsc-Fix-improve-RX-path-error-handling' · 9e096868
      David S. Miller authored
      Haiyang Zhang says:
      
      ====================
      hv_netvsc: Fix/improve RX path error handling
      
      Fix the status code returned to the host. Also add range
      check for rx packet offset and length.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9e096868
    • Haiyang Zhang's avatar
      hv_netvsc: Add range checking for rx packet offset and length · c5d24bdd
      Haiyang Zhang authored
      This patch adds range checking for rx packet offset and length.
      It may only happen if there is a host side bug.
      Signed-off-by: default avatarHaiyang Zhang <haiyangz@microsoft.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c5d24bdd
    • Haiyang Zhang's avatar
      hv_netvsc: Fix the return status in RX path · 5c71dadb
      Haiyang Zhang authored
      As defined in hyperv_net.h, the NVSP_STAT_SUCCESS is one not zero.
      Some functions returns 0 when it actually means NVSP_STAT_SUCCESS.
      This patch fixes them.
      
      In netvsc_receive(), it puts the last RNDIS packet's receive status
      for all packets in a vmxferpage which may contain multiple RNDIS
      packets.
      This patch puts NVSP_STAT_FAIL in the receive completion if one of
      the packets in a vmxferpage fails.
      Signed-off-by: default avatarHaiyang Zhang <haiyangz@microsoft.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5c71dadb
    • David S. Miller's avatar
      Merge branch 'net-permit-skb_segment-on-head_frag-frag_list-skb' · 74b4bed9
      David S. Miller authored
      Yonghong Song says:
      
      ====================
      net: permit skb_segment on head_frag frag_list skb
      
      One of our in-house projects, bpf-based NAT, hits a kernel BUG_ON at
      function skb_segment(), line 3667. The bpf program attaches to
      clsact ingress, calls bpf_skb_change_proto to change protocol
      from ipv4 to ipv6 or from ipv6 to ipv4, and then calls bpf_redirect
      to send the changed packet out.
       ...
          3665                 while (pos < offset + len) {
          3666                         if (i >= nfrags) {
          3667                                 BUG_ON(skb_headlen(list_skb));
       ...
      
      The triggering input skb has the following properties:
          list_skb = skb->frag_list;
          skb->nfrags != NULL && skb_headlen(list_skb) != 0
      and skb_segment() is not able to handle a frag_list skb
      if its headlen (list_skb->len - list_skb->data_len) is not 0.
      
      Patch #1 provides a simple solution to avoid BUG_ON. If
      list_skb->head_frag is true, its page-backed frag will
      be processed before the list_skb->frags.
      Patch #2 provides a test case in test_bpf module which
      constructs a skb and calls skb_segment() directly. The test
      case is able to trigger the BUG_ON without Patch #1.
      
      The patch has been tested in the following setup:
        ipv6_host <-> nat_server <-> ipv4_host
      where nat_server has a bpf program doing ipv4<->ipv6
      translation and forwarding through clsact hook
      bpf_skb_change_proto.
      
      Changelog:
      v5 -> v6:
        . Added back missed BUG_ON(!nfrags) for zero
          skb_headlen(skb) case, plus a couple of
          cosmetic changes, from Alexander.
      v4 -> v5:
        . Replace local variable head_frag with
          a static inline function skb_head_frag_to_page_desc
          which gets the head_frag on-demand. This makes
          code more readable and also does not increase
          the stack size, from Alexander.
        . Remove the "if(nfrags)" guard for skb_orphan_frags
          and skb_zerocopy_clone as I found that they can
          handle zero-frag skb (with non-zero skb_headlen(skb))
          properly.
        . Properly release segment list from skb_segment()
          in the test, from Eric.
      v3 -> v4:
        . Remove dynamic memory allocation and use rewinding
          for both index and frag to remove one branch in fast path,
          from Alexander.
        . Fix a bunch of issues in test_bpf skb_segment() test,
          including proper way to allocate skb, proper function
          argument for skb_add_rx_frag and not freeint skb, etc.,
          from Eric.
      v2 -> v3:
        . Use starting frag index -1 (instead of 0) to
          special process head_frag before other frags in the skb,
          from Alexander Duyck.
      v1 -> v2:
        . Removed never-hit BUG_ON, spotted by Linyu Yuan.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      74b4bed9
    • Yonghong Song's avatar
      net: bpf: add a test for skb_segment in test_bpf module · 76db8087
      Yonghong Song authored
      Without the previous commit,
      "modprobe test_bpf" will have the following errors:
      ...
      [   98.149165] ------------[ cut here ]------------
      [   98.159362] kernel BUG at net/core/skbuff.c:3667!
      [   98.169756] invalid opcode: 0000 [#1] SMP PTI
      [   98.179370] Modules linked in:
      [   98.179371]  test_bpf(+)
      ...
      which triggers the bug the previous commit intends to fix.
      
      The skbs are constructed to mimic what mlx5 may generate.
      The packet size/header may not mimic real cases in production. But
      the processing flow is similar.
      Signed-off-by: default avatarYonghong Song <yhs@fb.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      76db8087
    • Yonghong Song's avatar
      net: permit skb_segment on head_frag frag_list skb · 13acc94e
      Yonghong Song authored
      One of our in-house projects, bpf-based NAT, hits a kernel BUG_ON at
      function skb_segment(), line 3667. The bpf program attaches to
      clsact ingress, calls bpf_skb_change_proto to change protocol
      from ipv4 to ipv6 or from ipv6 to ipv4, and then calls bpf_redirect
      to send the changed packet out.
      
      3472 struct sk_buff *skb_segment(struct sk_buff *head_skb,
      3473                             netdev_features_t features)
      3474 {
      3475         struct sk_buff *segs = NULL;
      3476         struct sk_buff *tail = NULL;
      ...
      3665                 while (pos < offset + len) {
      3666                         if (i >= nfrags) {
      3667                                 BUG_ON(skb_headlen(list_skb));
      3668
      3669                                 i = 0;
      3670                                 nfrags = skb_shinfo(list_skb)->nr_frags;
      3671                                 frag = skb_shinfo(list_skb)->frags;
      3672                                 frag_skb = list_skb;
      ...
      
      call stack:
      ...
       #1 [ffff883ffef03558] __crash_kexec at ffffffff8110c525
       #2 [ffff883ffef03620] crash_kexec at ffffffff8110d5cc
       #3 [ffff883ffef03640] oops_end at ffffffff8101d7e7
       #4 [ffff883ffef03668] die at ffffffff8101deb2
       #5 [ffff883ffef03698] do_trap at ffffffff8101a700
       #6 [ffff883ffef036e8] do_error_trap at ffffffff8101abfe
       #7 [ffff883ffef037a0] do_invalid_op at ffffffff8101acd0
       #8 [ffff883ffef037b0] invalid_op at ffffffff81a00bab
          [exception RIP: skb_segment+3044]
          RIP: ffffffff817e4dd4  RSP: ffff883ffef03860  RFLAGS: 00010216
          RAX: 0000000000002bf6  RBX: ffff883feb7aaa00  RCX: 0000000000000011
          RDX: ffff883fb87910c0  RSI: 0000000000000011  RDI: ffff883feb7ab500
          RBP: ffff883ffef03928   R8: 0000000000002ce2   R9: 00000000000027da
          R10: 000001ea00000000  R11: 0000000000002d82  R12: ffff883f90a1ee80
          R13: ffff883fb8791120  R14: ffff883feb7abc00  R15: 0000000000002ce2
          ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
       #9 [ffff883ffef03930] tcp_gso_segment at ffffffff818713e7
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      13acc94e