Forum | Documentation | Website | Blog

Skip to content
Snippets Groups Projects
  1. Apr 01, 2022
    • Ziyang Xuan's avatar
      net/tls: fix slab-out-of-bounds bug in decrypt_internal · 9381fe8c
      Ziyang Xuan authored
      The memory size of tls_ctx->rx.iv for AES128-CCM is 12 setting in
      tls_set_sw_offload(). The return value of crypto_aead_ivsize()
      for "ccm(aes)" is 16. So memcpy() require 16 bytes from 12 bytes
      memory space will trigger slab-out-of-bounds bug as following:
      
      ==================================================================
      BUG: KASAN: slab-out-of-bounds in decrypt_internal+0x385/0xc40 [tls]
      Read of size 16 at addr ffff888114e84e60 by task tls/10911
      
      Call Trace:
       <TASK>
       dump_stack_lvl+0x34/0x44
       print_report.cold+0x5e/0x5db
       ? decrypt_internal+0x385/0xc40 [tls]
       kasan_report+0xab/0x120
       ? decrypt_internal+0x385/0xc40 [tls]
       kasan_check_range+0xf9/0x1e0
       memcpy+0x20/0x60
       decrypt_internal+0x385/0xc40 [tls]
       ? tls_get_rec+0x2e0/0x2e0 [tls]
       ? process_rx_list+0x1a5/0x420 [tls]
       ? tls_setup_from_iter.constprop.0+0x2e0/0x2e0 [tls]
       decrypt_skb_update+0x9d/0x400 [tls]
       tls_sw_recvmsg+0x3c8/0xb50 [tls]
      
      Allocated by task 10911:
       kasan_save_stack+0x1e/0x40
       __kasan_kmalloc+0x81/0xa0
       tls_set_sw_offload+0x2eb/0xa20 [tls]
       tls_setsockopt+0x68c/0x700 [tls]
       __sys_setsockopt+0xfe/0x1b0
      
      Replace the crypto_aead_ivsize() with prot->iv_size + prot->salt_size
      when memcpy() iv value in TLS_1_3_VERSION scenario.
      
      Fixes: f295b3ae
      
       ("net/tls: Add support of AES128-CCM based ciphers")
      Signed-off-by: default avatarZiyang Xuan <william.xuanziyang@huawei.com>
      Reviewed-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9381fe8c
    • Taehee Yoo's avatar
      net: sfc: add missing xdp queue reinitialization · 059a47f1
      Taehee Yoo authored
      After rx/tx ring buffer size is changed, kernel panic occurs when
      it acts XDP_TX or XDP_REDIRECT.
      
      When tx/rx ring buffer size is changed(ethtool -G), sfc driver
      reallocates and reinitializes rx and tx queues and their buffer
      (tx_queue->buffer).
      But it misses reinitializing xdp queues(efx->xdp_tx_queues).
      So, while it is acting XDP_TX or XDP_REDIRECT, it uses the uninitialized
      tx_queue->buffer.
      
      A new function efx_set_xdp_channels() is separated from efx_set_channels()
      to handle only xdp queues.
      
      Splat looks like:
         BUG: kernel NULL pointer dereference, address: 000000000000002a
         #PF: supervisor write access in kernel mode
         #PF: error_code(0x0002) - not-present page
         PGD 0 P4D 0
         Oops: 0002 [#4] PREEMPT SMP NOPTI
         RIP: 0010:efx_tx_map_chunk+0x54/0x90 [sfc]
         CPU: 2 PID: 0 Comm: swapper/2 Tainted: G      D           5.17.0+ #55 e8beeee8289528f11357029357cf
         Code: 48 8b 8d a8 01 00 00 48 8d 14 52 4c 8d 2c d0 44 89 e0 48 85 c9 74 0e 44 89 e2 4c 89 f6 48 80
         RSP: 0018:ffff92f121e45c60 EFLAGS: 00010297
         RIP: 0010:efx_tx_map_chunk+0x54/0x90 [sfc]
         RAX: 0000000000000040 RBX: ffff92ea506895c0 RCX: ffffffffc0330870
         RDX: 0000000000000001 RSI: 00000001139b10ce RDI: ffff92ea506895c0
         RBP: ffffffffc0358a80 R08: 00000001139b110d R09: 0000000000000000
         R10: 0000000000000001 R11: ffff92ea414c0088 R12: 0000000000000040
         R13: 0000000000000018 R14: 00000001139b10ce R15: ffff92ea506895c0
         FS:  0000000000000000(0000) GS:ffff92f121ec0000(0000) knlGS:0000000000000000
         CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
         Code: 48 8b 8d a8 01 00 00 48 8d 14 52 4c 8d 2c d0 44 89 e0 48 85 c9 74 0e 44 89 e2 4c 89 f6 48 80
         CR2: 000000000000002a CR3: 00000003e6810004 CR4: 00000000007706e0
         RSP: 0018:ffff92f121e85c60 EFLAGS: 00010297
         PKRU: 55555554
         RAX: 0000000000000040 RBX: ffff92ea50689700 RCX: ffffffffc0330870
         RDX: 0000000000000001 RSI: 00000001145a90ce RDI: ffff92ea50689700
         RBP: ffffffffc0358a80 R08: 00000001145a910d R09: 0000000000000000
         R10: 0000000000000001 R11: ffff92ea414c0088 R12: 0000000000000040
         R13: 0000000000000018 R14: 00000001145a90ce R15: ffff92ea50689700
         FS:  0000000000000000(0000) GS:ffff92f121e80000(0000) knlGS:0000000000000000
         CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
         CR2: 000000000000002a CR3: 00000003e6810005 CR4: 00000000007706e0
         PKRU: 55555554
         Call Trace:
          <IRQ>
          efx_xdp_tx_buffers+0x12b/0x3d0 [sfc 84c94b8e32d44d296c17e10a634d3ad454de4ba5]
          __efx_rx_packet+0x5c3/0x930 [sfc 84c94b8e32d44d296c17e10a634d3ad454de4ba5]
          efx_rx_packet+0x28c/0x2e0 [sfc 84c94b8e32d44d296c17e10a634d3ad454de4ba5]
          efx_ef10_ev_process+0x5f8/0xf40 [sfc 84c94b8e32d44d296c17e10a634d3ad454de4ba5]
          ? enqueue_task_fair+0x95/0x550
          efx_poll+0xc4/0x360 [sfc 84c94b8e32d44d296c17e10a634d3ad454de4ba5]
      
      Fixes: 3990a8ff
      
       ("sfc: allocate channels for XDP tx queues")
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      059a47f1
  2. Mar 31, 2022
  3. Mar 30, 2022
    • 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.org
      
      
      Signed-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.com
      
      
      Signed-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