1. 17 Nov, 2015 5 commits
    • Sabrina Dubroca's avatar
      ipvlan: fix leak in ipvlan_rcv_frame · cf554ada
      Sabrina Dubroca authored
      Pass a **skb to ipvlan_rcv_frame so that if skb_share_check returns a
      new skb, we actually use it during further processing.
      
      It's safe to ignore the new skb in the ipvlan_xmit_* functions, because
      they call ipvlan_rcv_frame with local == true, so that dev_forward_skb
      is called and always takes ownership of the skb.
      
      Fixes: 2ad7bf36 ("ipvlan: Initial check-in of the IPVLAN driver.")
      Signed-off-by: default avatarSabrina Dubroca <sd@queasysnail.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cf554ada
    • David S. Miller's avatar
      Merge branch 'vlan-reorder' · eb3f8b42
      David S. Miller authored
      Vladislav Yasevich says:
      
      ====================
      Fix issues with vlans without REORDER_HEADER
      
      A while ago Phil Sutter brought up an issue with vlans without
      REORDER_HEADER and bridges.  The problem was that if a vlan
      without REORDER_HEADER was a port in the bridge, the bridge ended
      up forwarding corrupted packets that still contained the vlan header.
      The same issue exists for bridge mode macvlan/macvtap devices.
      
      An additional issue with vlans without REORDER_HEADER is that stacking
      them also doesn't work.  The reason here is that skb_reorder_vlan_header()
      function assumes that it on ETH_HLEN bytes deep into the packet.  That
      is not the case, when you a vlan without REORRDER_HEADER flag set.
      
      This series attempts to correct these 2 issues.
      
      1) To solve the stacked vlans problem, the patch simply use
      skb->mac_len as an offset to start copying mac addresses that
      is part of header reordering.
      
      2) To fix the issue with bridge/macvlan/macvtap, the second patch
      simply doesn't write the vlan header back to the packet if the
      vlan device is either a bridge or a macvlan port.  This ends up
      being the simplest and least performance intrussive solution.
      
      I've considered extending patch 2 to all stacked devices (essentially
      checked for the presense of rx_handler), but that feels like a broader
      restriction and _may_ break existing uses.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      eb3f8b42
    • Vlad Yasevich's avatar
      vlan: Do not put vlan headers back on bridge and macvlan ports · 28f9ee22
      Vlad Yasevich authored
      When a vlan is configured with REORDER_HEADER set to 0, the vlan
      header is put back into the packet and makes it appear that
      the vlan header is still there even after it's been processed.
      This posses a problem for bridge and macvlan ports.  The packets
      passed to those device may be forwarded and at the time of the
      forward, vlan headers end up being unexpectedly present.
      
      With the patch, we make sure that we do not put the vlan header
      back (when REORDER_HEADER is 0) if a bridge or macvlan has
      been configured on top of the vlan device.
      Signed-off-by: default avatarVladislav Yasevich <vyasevic@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      28f9ee22
    • Vlad Yasevich's avatar
      vlan: Fix untag operations of stacked vlans with REORDER_HEADER off · a6e18ff1
      Vlad Yasevich authored
      When we have multiple stacked vlan devices all of which have
      turned off REORDER_HEADER flag, the untag operation does not
      locate the ethernet addresses correctly for nested vlans.
      The reason is that in case of REORDER_HEADER flag being off,
      the outer vlan headers are put back and the mac_len is adjusted
      to account for the presense of the header.  Then, the subsequent
      untag operation, for the next level vlan, always use VLAN_ETH_HLEN
      to locate the begining of the ethernet header and that ends up
      being a multiple of 4 bytes short of the actuall beginning
      of the mac header (the multiple depending on the how many vlan
      encapsulations ethere are).
      
      As a reslult, if there are multiple levles of vlan devices
      with REODER_HEADER being off, the recevied packets end up
      being dropped.
      
      To solve this, we use skb->mac_len as the offset.  The value
      is always set on receive path and starts out as a ETH_HLEN.
      The value is also updated when the vlan header manupations occur
      so we know it will be correct.
      Signed-off-by: default avatarVladislav Yasevich <vyasevic@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a6e18ff1
    • Timo Teräs's avatar
      via-velocity: unconditionally drop frames with bad l2 length · 6c606fa3
      Timo Teräs authored
      By default the driver allowed incorrect frames to be received. What is
      worse the code does not handle very short frames correctly. The FCS
      length is unconditionally subtracted, and the underflow can cause
      skb_put to be called with large number after implicit cast to unsigned.
      And indeed, an skb_over_panic() was observed with via-velocity.
      
      This removes the module parameter as it does not work in it's
      current state, and should be implemented via NETIF_F_RXALL if needed.
      Suggested-by: default avatarFrancois Romieu <romieu@fr.zoreil.com>
      Signed-off-by: default avatarTimo Teräs <timo.teras@iki.fi>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6c606fa3
  2. 16 Nov, 2015 35 commits