1. 15 Jun, 2019 3 commits
  2. 14 Jun, 2019 10 commits
  3. 12 Jun, 2019 16 commits
  4. 11 Jun, 2019 5 commits
    • David S. Miller's avatar
      Merge branch 'vxlan-geneve-linear' · 93c65f83
      David S. Miller authored
      Stefano Brivio says:
      
      ====================
      Don't assume linear buffers in error handlers for VXLAN and GENEVE
      
      Guillaume noticed the same issue fixed by commit 26fc181e ("fou, fou6:
      do not assume linear skbs") for fou and fou6 is also present in VXLAN and
      GENEVE error handlers: we can't assume linear buffers there, we need to
      use pskb_may_pull() instead.
      ====================
      Acked-by: default avatarGuillaume Nault <gnault@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      93c65f83
    • Stefano Brivio's avatar
      geneve: Don't assume linear buffers in error handler · eccc73a6
      Stefano Brivio authored
      In commit a0796644 ("geneve: ICMP error lookup handler") I wrongly
      assumed buffers from icmp_socket_deliver() would be linear. This is not
      the case: icmp_socket_deliver() only guarantees we have 8 bytes of linear
      data.
      
      Eric fixed this same issue for fou and fou6 in commits 26fc181e
      ("fou, fou6: do not assume linear skbs") and 5355ed63 ("fou, fou6:
      avoid uninit-value in gue_err() and gue6_err()").
      
      Use pskb_may_pull() instead of checking skb->len, and take into account
      the fact we later access the GENEVE header with udp_hdr(), so we also
      need to sum skb_transport_header() here.
      Reported-by: default avatarGuillaume Nault <gnault@redhat.com>
      Fixes: a0796644 ("geneve: ICMP error lookup handler")
      Signed-off-by: default avatarStefano Brivio <sbrivio@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      eccc73a6
    • Stefano Brivio's avatar
      vxlan: Don't assume linear buffers in error handler · 8399a693
      Stefano Brivio authored
      In commit c3a43b9f ("vxlan: ICMP error lookup handler") I wrongly
      assumed buffers from icmp_socket_deliver() would be linear. This is not
      the case: icmp_socket_deliver() only guarantees we have 8 bytes of linear
      data.
      
      Eric fixed this same issue for fou and fou6 in commits 26fc181e
      ("fou, fou6: do not assume linear skbs") and 5355ed63 ("fou, fou6:
      avoid uninit-value in gue_err() and gue6_err()").
      
      Use pskb_may_pull() instead of checking skb->len, and take into account
      the fact we later access the VXLAN header with udp_hdr(), so we also
      need to sum skb_transport_header() here.
      Reported-by: default avatarGuillaume Nault <gnault@redhat.com>
      Fixes: c3a43b9f ("vxlan: ICMP error lookup handler")
      Signed-off-by: default avatarStefano Brivio <sbrivio@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8399a693
    • Taehee Yoo's avatar
      net: openvswitch: do not free vport if register_netdevice() is failed. · 309b6697
      Taehee Yoo authored
      In order to create an internal vport, internal_dev_create() is used and
      that calls register_netdevice() internally.
      If register_netdevice() fails, it calls dev->priv_destructor() to free
      private data of netdev. actually, a private data of this is a vport.
      
      Hence internal_dev_create() should not free and use a vport after failure
      of register_netdevice().
      
      Test command
          ovs-dpctl add-dp bonding_masters
      
      Splat looks like:
      [ 1035.667767] kasan: GPF could be caused by NULL-ptr deref or user memory access
      [ 1035.675958] general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI
      [ 1035.676916] CPU: 1 PID: 1028 Comm: ovs-vswitchd Tainted: G    B             5.2.0-rc3+ #240
      [ 1035.676916] RIP: 0010:internal_dev_create+0x2e5/0x4e0 [openvswitch]
      [ 1035.676916] Code: 48 c1 ea 03 80 3c 02 00 0f 85 9f 01 00 00 4c 8b 23 48 b8 00 00 00 00 00 fc ff df 49 8d bc 24 60 05 00 00 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 86 01 00 00 49 8b bc 24 60 05 00 00 e8 e4 68 f4
      [ 1035.713720] RSP: 0018:ffff88810dcb7578 EFLAGS: 00010206
      [ 1035.713720] RAX: dffffc0000000000 RBX: ffff88810d13fe08 RCX: ffffffff84297704
      [ 1035.713720] RDX: 00000000000000ac RSI: 0000000000000000 RDI: 0000000000000560
      [ 1035.713720] RBP: 00000000ffffffef R08: fffffbfff0d3b881 R09: fffffbfff0d3b881
      [ 1035.713720] R10: 0000000000000001 R11: fffffbfff0d3b880 R12: 0000000000000000
      [ 1035.768776] R13: 0000607ee460b900 R14: ffff88810dcb7690 R15: ffff88810dcb7698
      [ 1035.777709] FS:  00007f02095fc980(0000) GS:ffff88811b400000(0000) knlGS:0000000000000000
      [ 1035.777709] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 1035.777709] CR2: 00007ffdf01d2f28 CR3: 0000000108258000 CR4: 00000000001006e0
      [ 1035.777709] Call Trace:
      [ 1035.777709]  ovs_vport_add+0x267/0x4f0 [openvswitch]
      [ 1035.777709]  new_vport+0x15/0x1e0 [openvswitch]
      [ 1035.777709]  ovs_vport_cmd_new+0x567/0xd10 [openvswitch]
      [ 1035.777709]  ? ovs_dp_cmd_dump+0x490/0x490 [openvswitch]
      [ 1035.777709]  ? __kmalloc+0x131/0x2e0
      [ 1035.777709]  ? genl_family_rcv_msg+0xa54/0x1030
      [ 1035.777709]  genl_family_rcv_msg+0x63a/0x1030
      [ 1035.777709]  ? genl_unregister_family+0x630/0x630
      [ 1035.841681]  ? debug_show_all_locks+0x2d0/0x2d0
      [ ... ]
      
      Fixes: cf124db5 ("net: Fix inconsistent teardown and release of private netdev state.")
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Reviewed-by: default avatarGreg Rose <gvrose8192@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      309b6697
    • Willem de Bruijn's avatar
      net: correct udp zerocopy refcnt also when zerocopy only on append · 522924b5
      Willem de Bruijn authored
      The below patch fixes an incorrect zerocopy refcnt increment when
      appending with MSG_MORE to an existing zerocopy udp skb.
      
        send(.., MSG_ZEROCOPY | MSG_MORE);	// refcnt 1
        send(.., MSG_ZEROCOPY | MSG_MORE);	// refcnt still 1 (bar frags)
      
      But it missed that zerocopy need not be passed at the first send. The
      right test whether the uarg is newly allocated and thus has extra
      refcnt 1 is not !skb, but !skb_zcopy.
      
        send(.., MSG_MORE);			// <no uarg>
        send(.., MSG_ZEROCOPY);		// refcnt 1
      
      Fixes: 100f6d8e ("net: correct zerocopy refcnt with udp MSG_MORE")
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      522924b5
  5. 10 Jun, 2019 6 commits