1. 04 6月, 2019 5 次提交
    • E
      ipv4/igmp: fix build error if !CONFIG_IP_MULTICAST · 46702dd5
      Eric Dumazet 提交于
      [ Upstream commit 903869bd10e6719b9df6718e785be7ec725df59f ]
      
      ip_sf_list_clear_all() needs to be defined even if !CONFIG_IP_MULTICAST
      
      Fixes: 3580d04aa674 ("ipv4/igmp: fix another memory leak in igmpv3_del_delrec()")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: Nkbuild test robot <lkp@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      46702dd5
    • E
      ipv4/igmp: fix another memory leak in igmpv3_del_delrec() · e9f94e48
      Eric Dumazet 提交于
      [ Upstream commit 3580d04aa674383c42de7b635d28e52a1e5bc72c ]
      
      syzbot reported memory leaks [1] that I have back tracked to
      a missing cleanup from igmpv3_del_delrec() when
      (im->sfmode != MCAST_INCLUDE)
      
      Add ip_sf_list_clear_all() and kfree_pmc() helpers to explicitely
      handle the cleanups before freeing.
      
      [1]
      
      BUG: memory leak
      unreferenced object 0xffff888123e32b00 (size 64):
        comm "softirq", pid 0, jiffies 4294942968 (age 8.010s)
        hex dump (first 32 bytes):
          00 00 00 00 00 00 00 00 e0 00 00 01 00 00 00 00  ................
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        backtrace:
          [<000000006105011b>] kmemleak_alloc_recursive include/linux/kmemleak.h:55 [inline]
          [<000000006105011b>] slab_post_alloc_hook mm/slab.h:439 [inline]
          [<000000006105011b>] slab_alloc mm/slab.c:3326 [inline]
          [<000000006105011b>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553
          [<000000004bba8073>] kmalloc include/linux/slab.h:547 [inline]
          [<000000004bba8073>] kzalloc include/linux/slab.h:742 [inline]
          [<000000004bba8073>] ip_mc_add1_src net/ipv4/igmp.c:1961 [inline]
          [<000000004bba8073>] ip_mc_add_src+0x36b/0x400 net/ipv4/igmp.c:2085
          [<00000000a46a65a0>] ip_mc_msfilter+0x22d/0x310 net/ipv4/igmp.c:2475
          [<000000005956ca89>] do_ip_setsockopt.isra.0+0x1795/0x1930 net/ipv4/ip_sockglue.c:957
          [<00000000848e2d2f>] ip_setsockopt+0x3b/0xb0 net/ipv4/ip_sockglue.c:1246
          [<00000000b9db185c>] udp_setsockopt+0x4e/0x90 net/ipv4/udp.c:2616
          [<000000003028e438>] sock_common_setsockopt+0x38/0x50 net/core/sock.c:3130
          [<0000000015b65589>] __sys_setsockopt+0x98/0x120 net/socket.c:2078
          [<00000000ac198ef0>] __do_sys_setsockopt net/socket.c:2089 [inline]
          [<00000000ac198ef0>] __se_sys_setsockopt net/socket.c:2086 [inline]
          [<00000000ac198ef0>] __x64_sys_setsockopt+0x26/0x30 net/socket.c:2086
          [<000000000a770437>] do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:301
          [<00000000d3adb93b>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Fixes: 9c8bb163 ("igmp, mld: Fix memory leak in igmpv3/mld_del_delrec()")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Hangbin Liu <liuhangbin@gmail.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e9f94e48
    • E
      inet: switch IP ID generator to siphash · 07480da0
      Eric Dumazet 提交于
      [ Upstream commit df453700e8d81b1bdafdf684365ee2b9431fb702 ]
      
      According to Amit Klein and Benny Pinkas, IP ID generation is too weak
      and might be used by attackers.
      
      Even with recent net_hash_mix() fix (netns: provide pure entropy for net_hash_mix())
      having 64bit key and Jenkins hash is risky.
      
      It is time to switch to siphash and its 128bit keys.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: NAmit Klein <aksecurity@gmail.com>
      Reported-by: NBenny Pinkas <benny@pinkas.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      07480da0
    • R
      cxgb4: offload VLAN flows regardless of VLAN ethtype · 9c9144e7
      Raju Rangoju 提交于
      [ Upstream commit b5730061d1056abf317caea823b94d6e12b5b4f6 ]
      
      VLAN flows never get offloaded unless ivlan_vld is set in filter spec.
      It's not compulsory for vlan_ethtype to be set.
      
      So, always enable ivlan_vld bit for offloading VLAN flows regardless of
      vlan_ethtype is set or not.
      
      Fixes: ad9af3e0 (cxgb4: add tc flower match support for vlan)
      Signed-off-by: NRaju Rangoju <rajur@chelsio.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9c9144e7
    • J
      bonding/802.3ad: fix slave link initialization transition states · 3cde0a25
      Jarod Wilson 提交于
      [ Upstream commit 334031219a84b9994594015aab85ed7754c80176 ]
      
      Once in a while, with just the right timing, 802.3ad slaves will fail to
      properly initialize, winding up in a weird state, with a partner system
      mac address of 00:00:00:00:00:00. This started happening after a fix to
      properly track link_failure_count tracking, where an 802.3ad slave that
      reported itself as link up in the miimon code, but wasn't able to get a
      valid speed/duplex, started getting set to BOND_LINK_FAIL instead of
      BOND_LINK_DOWN. That was the proper thing to do for the general "my link
      went down" case, but has created a link initialization race that can put
      the interface in this odd state.
      
      The simple fix is to instead set the slave link to BOND_LINK_DOWN again,
      if the link has never been up (last_link_up == 0), so the link state
      doesn't bounce from BOND_LINK_DOWN to BOND_LINK_FAIL -- it hasn't failed
      in this case, it simply hasn't been up yet, and this prevents the
      unnecessary state change from DOWN to FAIL and getting stuck in an init
      failure w/o a partner mac.
      
      Fixes: ea53abfab960 ("bonding/802.3ad: fix link_failure_count tracking")
      CC: Jay Vosburgh <j.vosburgh@gmail.com>
      CC: Veaceslav Falico <vfalico@gmail.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      CC: "David S. Miller" <davem@davemloft.net>
      CC: netdev@vger.kernel.org
      Tested-by: NHeesoon Kim <Heesoon.Kim@stratus.com>
      Signed-off-by: NJarod Wilson <jarod@redhat.com>
      Acked-by: NJay Vosburgh <jay.vosburgh@canonical.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3cde0a25
  2. 31 5月, 2019 35 次提交