1. 31 Mar, 2022 6 commits
    • Randy Dunlap's avatar
      net: sparx5: uses, depends on BRIDGE or !BRIDGE · f9512d65
      Randy Dunlap authored
      Fix build errors when BRIDGE=m and SPARX5_SWITCH=y:
      
      riscv64-linux-ld: drivers/net/ethernet/microchip/sparx5/sparx5_switchdev.o: in function `.L305':
      sparx5_switchdev.c:(.text+0xdb0): undefined reference to `br_vlan_enabled'
      riscv64-linux-ld: drivers/net/ethernet/microchip/sparx5/sparx5_switchdev.o: in function `.L283':
      sparx5_switchdev.c:(.text+0xee0): undefined reference to `br_vlan_enabled'
      
      Fixes: 3cfa11ba ("net: sparx5: add the basic sparx5 driver")
      Signed-off-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Reported-by: default avatarkernel test robot <lkp@intel.com>
      Cc: Horatiu Vultur <horatiu.vultur@microchip.com>
      Cc: Lars Povlsen <lars.povlsen@microchip.com>
      Cc: Steen Hegelund <Steen.Hegelund@microchip.com>
      Cc: UNGLinuxDriver@microchip.com
      Cc: Paolo Abeni <pabeni@redhat.com>
      Link: https://lore.kernel.org/r/20220330012025.29560-1-rdunlap@infradead.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      f9512d65
    • Jakub Kicinski's avatar
      Merge branch 'wireguard-patches-for-5-18-rc1' · 1f686f2b
      Jakub Kicinski authored
      Jason A. Donenfeld says:
      
      ====================
      wireguard patches for 5.18-rc1
      
      Here's a small set of fixes for the next net push:
      
      1) Pipacs reported a CFI violation in a cleanup routine, which he
         triggered using grsec's RAP. I haven't seen reports of this yet from
         the Android/CFI world yet, but it's only a matter of time there.
      
      2) A small rng cleanup to the self test harness to make it initialize
         faster on 5.18.
      
      3) Wang reported and fixed a skb leak for CONFIG_IPV6=n.
      
      4) After Wang's fix for the direct leak, I investigated how that code
         path even could be hit, and found that the netlink layer still
         handles IPv6 endpoints, when it probably shouldn't.
      ====================
      
      Link: https://lore.kernel.org/r/20220330013127.426620-1-Jason@zx2c4.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      1f686f2b
    • Jason A. Donenfeld's avatar
      wireguard: socket: ignore v6 endpoints when ipv6 is disabled · 77fc73ac
      Jason A. Donenfeld authored
      The previous commit fixed a memory leak on the send path in the event
      that IPv6 is disabled at compile time, but how did a packet even arrive
      there to begin with? It turns out we have previously allowed IPv6
      endpoints even when IPv6 support is disabled at compile time. This is
      awkward and inconsistent. Instead, let's just ignore all things IPv6,
      the same way we do other malformed endpoints, in the case where IPv6 is
      disabled.
      
      Fixes: e7096c13 ("net: WireGuard secure network tunnel")
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      77fc73ac
    • Wang Hai's avatar
      wireguard: socket: free skb in send6 when ipv6 is disabled · bbbf962d
      Wang Hai authored
      I got a memory leak report:
      
      unreferenced object 0xffff8881191fc040 (size 232):
        comm "kworker/u17:0", pid 23193, jiffies 4295238848 (age 3464.870s)
        hex dump (first 32 bytes):
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        backtrace:
          [<ffffffff814c3ef4>] slab_post_alloc_hook+0x84/0x3b0
          [<ffffffff814c8977>] kmem_cache_alloc_node+0x167/0x340
          [<ffffffff832974fb>] __alloc_skb+0x1db/0x200
          [<ffffffff82612b5d>] wg_socket_send_buffer_to_peer+0x3d/0xc0
          [<ffffffff8260e94a>] wg_packet_send_handshake_initiation+0xfa/0x110
          [<ffffffff8260ec81>] wg_packet_handshake_send_worker+0x21/0x30
          [<ffffffff8119c558>] process_one_work+0x2e8/0x770
          [<ffffffff8119ca2a>] worker_thread+0x4a/0x4b0
          [<ffffffff811a88e0>] kthread+0x120/0x160
          [<ffffffff8100242f>] ret_from_fork+0x1f/0x30
      
      In function wg_socket_send_buffer_as_reply_to_skb() or wg_socket_send_
      buffer_to_peer(), the semantics of send6() is required to free skb. But
      when CONFIG_IPV6 is disable, kfree_skb() is missing. This patch adds it
      to fix this bug.
      Signed-off-by: default avatarWang Hai <wanghai38@huawei.com>
      Fixes: e7096c13 ("net: WireGuard secure network tunnel")
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      bbbf962d
    • Jason A. Donenfeld's avatar
      wireguard: selftests: simplify RNG seeding · ca93ca23
      Jason A. Donenfeld authored
      The seed_rng() function was written to work across lots of old kernels,
      back when WireGuard used a big compatibility layer. Now that things have
      evolved, we can vastly simplify this, by just marking the RNG as seeded.
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      ca93ca23
    • Jason A. Donenfeld's avatar
      wireguard: queueing: use CFI-safe ptr_ring cleanup function · ec59f128
      Jason A. Donenfeld authored
      We make too nuanced use of ptr_ring to entirely move to the skb_array
      wrappers, but we at least should avoid the naughty function pointer cast
      when cleaning up skbs. Otherwise RAP/CFI will honk at us. This patch
      uses the __skb_array_destroy_skb wrapper for the cleanup, rather than
      directly providing kfree_skb, which is what other drivers in the same
      situation do too.
      Reported-by: default avatarPaX Team <pageexec@freemail.hu>
      Fixes: 886fcee9 ("wireguard: receive: use ring buffer for incoming handshakes")
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      ec59f128
  2. 30 Mar, 2022 4 commits
  3. 29 Mar, 2022 26 commits
  4. 28 Mar, 2022 4 commits