1. 11 Mar, 2019 14 commits
    • Kangjie Lu's avatar
      net: rocker: fix a potential NULL pointer dereference · 5c149314
      Kangjie Lu authored
      In case kzalloc fails, the fix releases resources and returns
      NOTIFY_BAD to avoid NULL pointer dereference.
      Signed-off-by: default avatarKangjie Lu <kjlu@umn.edu>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5c149314
    • Kangjie Lu's avatar
      net: qlge: fix a potential NULL pointer dereference · 4280b730
      Kangjie Lu authored
      In case alloc_ordered_workqueue fails, the fix returns
      -ENOMEM to avoid NULL pointer dereference.
      Signed-off-by: default avatarKangjie Lu <kjlu@umn.edu>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4280b730
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf · ab0891f5
      David S. Miller authored
      Pablo Neira Ayuso says:
      
      ====================
      Netfilter fixes for net
      
      The following patchset contains Netfilter fixes for your net tree:
      
      1) Fix list corruption in device notifier in the masquerade
         infrastructure, from Florian Westphal.
      
      2) Fix double-free of sets and use-after-free when deleting elements.
      
      3) Don't bogusly return EBUSY when removing a set after flush command.
      
      4) Use-after-free in dynamically allocate operations.
      
      5) Don't report a new ruleset generation to userspace if transaction
         list is empty, this invalidates the userspace cache innecessarily.
         From Florian Westphal.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ab0891f5
    • Eric Dumazet's avatar
      net/x25: reset state in x25_connect() · ee74d0bd
      Eric Dumazet authored
      In case x25_connect() fails and frees the socket neighbour,
      we also need to undo the change done to x25->state.
      
      Before my last bug fix, we had use-after-free so this
      patch fixes a latent bug.
      
      syzbot report :
      
      kasan: CONFIG_KASAN_INLINE enabled
      kasan: GPF could be caused by NULL-ptr deref or user memory access
      general protection fault: 0000 [#1] PREEMPT SMP KASAN
      CPU: 1 PID: 16137 Comm: syz-executor.1 Not tainted 5.0.0+ #117
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      RIP: 0010:x25_write_internal+0x1e8/0xdf0 net/x25/x25_subr.c:173
      Code: 00 40 88 b5 e0 fe ff ff 0f 85 01 0b 00 00 48 8b 8b 80 04 00 00 48 ba 00 00 00 00 00 fc ff df 48 8d 79 1c 48 89 fe 48 c1 ee 03 <0f> b6 34 16 48 89 fa 83 e2 07 83 c2 03 40 38 f2 7c 09 40 84 f6 0f
      RSP: 0018:ffff888076717a08 EFLAGS: 00010207
      RAX: ffff88805f2f2292 RBX: ffff8880a0ae6000 RCX: 0000000000000000
      kobject: 'loop5' (0000000018d0d0ee): kobject_uevent_env
      RDX: dffffc0000000000 RSI: 0000000000000003 RDI: 000000000000001c
      RBP: ffff888076717b40 R08: ffff8880950e0580 R09: ffffed100be5e46d
      R10: ffffed100be5e46c R11: ffff88805f2f2363 R12: ffff888065579840
      kobject: 'loop5' (0000000018d0d0ee): fill_kobj_path: path = '/devices/virtual/block/loop5'
      R13: 1ffff1100ece2f47 R14: 0000000000000013 R15: 0000000000000013
      FS:  00007fb88cf43700(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007f9a42a41028 CR3: 0000000087a67000 CR4: 00000000001406e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       x25_release+0xd0/0x340 net/x25/af_x25.c:658
       __sock_release+0xd3/0x2b0 net/socket.c:579
       sock_close+0x1b/0x30 net/socket.c:1162
       __fput+0x2df/0x8d0 fs/file_table.c:278
       ____fput+0x16/0x20 fs/file_table.c:309
       task_work_run+0x14a/0x1c0 kernel/task_work.c:113
       get_signal+0x1961/0x1d50 kernel/signal.c:2388
       do_signal+0x87/0x1940 arch/x86/kernel/signal.c:816
       exit_to_usermode_loop+0x244/0x2c0 arch/x86/entry/common.c:162
       prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
       syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
       do_syscall_64+0x52d/0x610 arch/x86/entry/common.c:293
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x457f29
      Code: ad b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007fb88cf42c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002a
      RAX: fffffffffffffe00 RBX: 0000000000000003 RCX: 0000000000457f29
      RDX: 0000000000000012 RSI: 0000000020000080 RDI: 0000000000000004
      RBP: 000000000073bf00 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00007fb88cf436d4
      R13: 00000000004be462 R14: 00000000004cec98 R15: 00000000ffffffff
      Modules linked in:
      
      Fixes: 95d6ebd5 ("net/x25: fix use-after-free in x25_device_event()")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: andrew hendry <andrew.hendry@gmail.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ee74d0bd
    • Christoph Paasch's avatar
      tcp: Don't access TCP_SKB_CB before initializing it · f2feaefd
      Christoph Paasch authored
      Since commit eeea10b8 ("tcp: add
      tcp_v4_fill_cb()/tcp_v4_restore_cb()"), tcp_vX_fill_cb is only called
      after tcp_filter(). That means, TCP_SKB_CB(skb)->end_seq still points to
      the IP-part of the cb.
      
      We thus should not mock with it, as this can trigger bugs (thanks
      syzkaller):
      [   12.349396] ==================================================================
      [   12.350188] BUG: KASAN: slab-out-of-bounds in ip6_datagram_recv_specific_ctl+0x19b3/0x1a20
      [   12.351035] Read of size 1 at addr ffff88006adbc208 by task test_ip6_datagr/1799
      
      Setting end_seq is actually no more necessary in tcp_filter as it gets
      initialized later on in tcp_vX_fill_cb.
      
      Cc: Eric Dumazet <edumazet@google.com>
      Fixes: eeea10b8 ("tcp: add tcp_v4_fill_cb()/tcp_v4_restore_cb()")
      Signed-off-by: default avatarChristoph Paasch <cpaasch@apple.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f2feaefd
    • Kangjie Lu's avatar
      net: thunder: fix a potential NULL pointer dereference · 0b31d98d
      Kangjie Lu authored
      In case alloc_ordered_workqueue fails, the fix reports the error
      and returns -ENOMEM.
      Signed-off-by: default avatarKangjie Lu <kjlu@umn.edu>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0b31d98d
    • Kangjie Lu's avatar
      net: lio_core: fix two NULL pointer dereferences · 41af8b3a
      Kangjie Lu authored
      In case octeon_alloc_soft_command fails, the fix reports the
      error and returns to avoid NULL pointer dereferences.
      Signed-off-by: default avatarKangjie Lu <kjlu@umn.edu>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      41af8b3a
    • Bryan Whitehead's avatar
      lan743x: Fix RX Kernel Panic · dd9d9f59
      Bryan Whitehead authored
      It has been noticed that running the speed test at
      www.speedtest.net occasionally causes a kernel panic.
      
      Investigation revealed that under this test RX buffer allocation
      sometimes fails and returns NULL. But the lan743x driver did
      not handle this case.
      
      This patch fixes this issue by attempting to allocate a buffer
      before sending the new rx packet to the OS. If the allocation
      fails then the new rx packet is dropped and the existing buffer
      is reused in the DMA ring.
      
      Updates for v2:
          Additional 2 locations where allocation was not checked,
              has been changed to reuse existing buffer.
      
      Fixes: 23f0703c ("lan743x: Add main source files for new lan743x driver")
      Signed-off-by: default avatarBryan Whitehead <Bryan.Whitehead@microchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      dd9d9f59
    • Florian Westphal's avatar
      netfilter: nf_tables: return immediately on empty commit · b8b27498
      Florian Westphal authored
      When running 'nft flush ruleset' while no rules exist, we will increment
      the generation counter and announce a new genid to userspace, yet
      nothing had changed in the first place.
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      b8b27498
    • Kangjie Lu's avatar
      net: liquidio: fix a NULL pointer dereference · fe543b2f
      Kangjie Lu authored
      In case octeon_alloc_soft_command fails, the fix reports the
      error and returns to avoid NULL pointer dereference.
      Signed-off-by: default avatarKangjie Lu <kjlu@umn.edu>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fe543b2f
    • Arnd Bergmann's avatar
      y2038: fix socket.h header inclusion · a623a7a1
      Arnd Bergmann authored
      Referencing the __kernel_long_t type caused some user space applications
      to stop compiling when they had not already included linux/posix_types.h,
      e.g.
      
      s/multicast.c -o ext/sockets/multicast.lo
      In file included from /builddir/build/BUILD/php-7.3.3/main/php.h:468,
                       from /builddir/build/BUILD/php-7.3.3/ext/sockets/sockets.c:27:
      /builddir/build/BUILD/php-7.3.3/ext/sockets/sockets.c: In function 'zm_startup_sockets':
      /builddir/build/BUILD/php-7.3.3/ext/sockets/sockets.c:776:40: error: '__kernel_long_t' undeclared (first use in this function)
        776 |  REGISTER_LONG_CONSTANT("SO_SNDTIMEO", SO_SNDTIMEO, CONST_CS | CONST_PERSISTENT);
      
      It is safe to include that header here, since it only contains kernel
      internal types that do not conflict with other user space types.
      
      It's still possible that some related build failures remain, but those
      are likely to be for code that is not already y2038 safe.
      Reported-by: default avatarLaura Abbott <labbott@redhat.com>
      Fixes: a9beb86a ("sock: Add SO_RCVTIMEO_NEW and SO_SNDTIMEO_NEW")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a623a7a1
    • Miaohe Lin's avatar
      net: sit: fix UBSAN Undefined behaviour in check_6rd · a843dc4e
      Miaohe Lin authored
      In func check_6rd,tunnel->ip6rd.relay_prefixlen may equal to
      32,so UBSAN complain about it.
      
      UBSAN: Undefined behaviour in net/ipv6/sit.c:781:47
      shift exponent 32 is too large for 32-bit type 'unsigned int'
      CPU: 6 PID: 20036 Comm: syz-executor.0 Not tainted 4.19.27 #2
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1
      04/01/2014
      Call Trace:
      __dump_stack lib/dump_stack.c:77 [inline]
      dump_stack+0xca/0x13e lib/dump_stack.c:113
      ubsan_epilogue+0xe/0x81 lib/ubsan.c:159
      __ubsan_handle_shift_out_of_bounds+0x293/0x2e8 lib/ubsan.c:425
      check_6rd.constprop.9+0x433/0x4e0 net/ipv6/sit.c:781
      try_6rd net/ipv6/sit.c:806 [inline]
      ipip6_tunnel_xmit net/ipv6/sit.c:866 [inline]
      sit_tunnel_xmit+0x141c/0x2720 net/ipv6/sit.c:1033
      __netdev_start_xmit include/linux/netdevice.h:4300 [inline]
      netdev_start_xmit include/linux/netdevice.h:4309 [inline]
      xmit_one net/core/dev.c:3243 [inline]
      dev_hard_start_xmit+0x17c/0x780 net/core/dev.c:3259
      __dev_queue_xmit+0x1656/0x2500 net/core/dev.c:3829
      neigh_output include/net/neighbour.h:501 [inline]
      ip6_finish_output2+0xa36/0x2290 net/ipv6/ip6_output.c:120
      ip6_finish_output+0x3e7/0xa20 net/ipv6/ip6_output.c:154
      NF_HOOK_COND include/linux/netfilter.h:278 [inline]
      ip6_output+0x1e2/0x720 net/ipv6/ip6_output.c:171
      dst_output include/net/dst.h:444 [inline]
      ip6_local_out+0x99/0x170 net/ipv6/output_core.c:176
      ip6_send_skb+0x9d/0x2f0 net/ipv6/ip6_output.c:1697
      ip6_push_pending_frames+0xc0/0x100 net/ipv6/ip6_output.c:1717
      rawv6_push_pending_frames net/ipv6/raw.c:616 [inline]
      rawv6_sendmsg+0x2435/0x3530 net/ipv6/raw.c:946
      inet_sendmsg+0xf8/0x5c0 net/ipv4/af_inet.c:798
      sock_sendmsg_nosec net/socket.c:621 [inline]
      sock_sendmsg+0xc8/0x110 net/socket.c:631
      ___sys_sendmsg+0x6cf/0x890 net/socket.c:2114
      __sys_sendmsg+0xf0/0x1b0 net/socket.c:2152
      do_syscall_64+0xc8/0x580 arch/x86/entry/common.c:290
      entry_SYSCALL_64_after_hwframe+0x49/0xbe
      Signed-off-by: default avatarlinmiaohe <linmiaohe@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a843dc4e
    • Pablo Neira Ayuso's avatar
      netfilter: nf_tables: use-after-free in dynamic operations · 3f3a390d
      Pablo Neira Ayuso authored
      Smatch reports:
      
             net/netfilter/nf_tables_api.c:2167 nf_tables_expr_destroy()
              error: dereferencing freed memory 'expr->ops'
      
      net/netfilter/nf_tables_api.c
          2162 static void nf_tables_expr_destroy(const struct nft_ctx *ctx,
          2163                                   struct nft_expr *expr)
          2164 {
          2165        if (expr->ops->destroy)
          2166                expr->ops->destroy(ctx, expr);
                                                      ^^^^
      --> 2167        module_put(expr->ops->type->owner);
                                 ^^^^^^^^^
          2168 }
      
      Smatch says there are three functions which free expr->ops.
      
      Fixes: b8e20400 ("netfilter: nft_compat: use .release_ops and remove list of extension")
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      3f3a390d
    • Pablo Neira Ayuso's avatar
      netfilter: nf_tables: bogus EBUSY when deleting set after flush · 273fe3f1
      Pablo Neira Ayuso authored
      Set deletion after flush coming in the same batch results in EBUSY. Add
      set use counter to track the number of references to this set from
      rules. We cannot rely on the list of bindings for this since such list
      is still populated from the preparation phase.
      Reported-by: default avatarVáclav Zindulka <vaclav.zindulka@tlapnet.cz>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      273fe3f1
  2. 10 Mar, 2019 7 commits
    • Eric Dumazet's avatar
      gro_cells: make sure device is up in gro_cells_receive() · 2a5ff07a
      Eric Dumazet authored
      We keep receiving syzbot reports [1] that show that tunnels do not play
      the rcu/IFF_UP rules properly.
      
      At device dismantle phase, gro_cells_destroy() will be called
      only after a full rcu grace period is observed after IFF_UP
      has been cleared.
      
      This means that IFF_UP needs to be tested before queueing packets
      into netif_rx() or gro_cells.
      
      This patch implements the test in gro_cells_receive() because
      too many callers do not seem to bother enough.
      
      [1]
      BUG: unable to handle kernel paging request at fffff4ca0b9ffffe
      PGD 0 P4D 0
      Oops: 0000 [#1] PREEMPT SMP KASAN
      CPU: 0 PID: 21 Comm: kworker/u4:1 Not tainted 5.0.0+ #97
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Workqueue: netns cleanup_net
      RIP: 0010:__skb_unlink include/linux/skbuff.h:1929 [inline]
      RIP: 0010:__skb_dequeue include/linux/skbuff.h:1945 [inline]
      RIP: 0010:__skb_queue_purge include/linux/skbuff.h:2656 [inline]
      RIP: 0010:gro_cells_destroy net/core/gro_cells.c:89 [inline]
      RIP: 0010:gro_cells_destroy+0x19d/0x360 net/core/gro_cells.c:78
      Code: 03 42 80 3c 20 00 0f 85 53 01 00 00 48 8d 7a 08 49 8b 47 08 49 c7 07 00 00 00 00 48 89 f9 49 c7 47 08 00 00 00 00 48 c1 e9 03 <42> 80 3c 21 00 0f 85 10 01 00 00 48 89 c1 48 89 42 08 48 c1 e9 03
      RSP: 0018:ffff8880aa3f79a8 EFLAGS: 00010a02
      RAX: 00ffffffffffffe8 RBX: ffffe8ffffc64b70 RCX: 1ffff8ca0b9ffffe
      RDX: ffffc6505cffffe8 RSI: ffffffff858410ca RDI: ffffc6505cfffff0
      RBP: ffff8880aa3f7a08 R08: ffff8880aa3e8580 R09: fffffbfff1263645
      R10: fffffbfff1263644 R11: ffffffff8931b223 R12: dffffc0000000000
      R13: 0000000000000000 R14: ffffe8ffffc64b80 R15: ffffe8ffffc64b75
      kobject: 'loop2' (000000004bd7d84a): kobject_uevent_env
      FS:  0000000000000000(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: fffff4ca0b9ffffe CR3: 0000000094941000 CR4: 00000000001406f0
      Call Trace:
      kobject: 'loop2' (000000004bd7d84a): fill_kobj_path: path = '/devices/virtual/block/loop2'
       ip_tunnel_dev_free+0x19/0x60 net/ipv4/ip_tunnel.c:1010
       netdev_run_todo+0x51c/0x7d0 net/core/dev.c:8970
       rtnl_unlock+0xe/0x10 net/core/rtnetlink.c:116
       ip_tunnel_delete_nets+0x423/0x5f0 net/ipv4/ip_tunnel.c:1124
       vti_exit_batch_net+0x23/0x30 net/ipv4/ip_vti.c:495
       ops_exit_list.isra.0+0x105/0x160 net/core/net_namespace.c:156
       cleanup_net+0x3fb/0x960 net/core/net_namespace.c:551
       process_one_work+0x98e/0x1790 kernel/workqueue.c:2173
       worker_thread+0x98/0xe40 kernel/workqueue.c:2319
       kthread+0x357/0x430 kernel/kthread.c:246
       ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
      Modules linked in:
      CR2: fffff4ca0b9ffffe
         [ end trace 513fc9c1338d1cb3 ]
      RIP: 0010:__skb_unlink include/linux/skbuff.h:1929 [inline]
      RIP: 0010:__skb_dequeue include/linux/skbuff.h:1945 [inline]
      RIP: 0010:__skb_queue_purge include/linux/skbuff.h:2656 [inline]
      RIP: 0010:gro_cells_destroy net/core/gro_cells.c:89 [inline]
      RIP: 0010:gro_cells_destroy+0x19d/0x360 net/core/gro_cells.c:78
      Code: 03 42 80 3c 20 00 0f 85 53 01 00 00 48 8d 7a 08 49 8b 47 08 49 c7 07 00 00 00 00 48 89 f9 49 c7 47 08 00 00 00 00 48 c1 e9 03 <42> 80 3c 21 00 0f 85 10 01 00 00 48 89 c1 48 89 42 08 48 c1 e9 03
      RSP: 0018:ffff8880aa3f79a8 EFLAGS: 00010a02
      RAX: 00ffffffffffffe8 RBX: ffffe8ffffc64b70 RCX: 1ffff8ca0b9ffffe
      RDX: ffffc6505cffffe8 RSI: ffffffff858410ca RDI: ffffc6505cfffff0
      RBP: ffff8880aa3f7a08 R08: ffff8880aa3e8580 R09: fffffbfff1263645
      R10: fffffbfff1263644 R11: ffffffff8931b223 R12: dffffc0000000000
      kobject: 'loop3' (00000000e4ee57a6): kobject_uevent_env
      R13: 0000000000000000 R14: ffffe8ffffc64b80 R15: ffffe8ffffc64b75
      FS:  0000000000000000(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: fffff4ca0b9ffffe CR3: 0000000094941000 CR4: 00000000001406f0
      
      Fixes: c9e6bc64 ("net: add gro_cells infrastructure")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2a5ff07a
    • Eric Dumazet's avatar
      vxlan: test dev->flags & IFF_UP before calling gro_cells_receive() · 59cbf56f
      Eric Dumazet authored
      Same reasons than the ones explained in commit 4179cb5a
      ("vxlan: test dev->flags & IFF_UP before calling netif_rx()")
      
      netif_rx() or gro_cells_receive() must be called under a strict contract.
      
      At device dismantle phase, core networking clears IFF_UP
      and flush_all_backlogs() is called after rcu grace period
      to make sure no incoming packet might be in a cpu backlog
      and still referencing the device.
      
      A similar protocol is used for gro_cells infrastructure, as
      gro_cells_destroy() will be called only after a full rcu
      grace period is observed after IFF_UP has been cleared.
      
      Most drivers call netif_rx() from their interrupt handler,
      and since the interrupts are disabled at device dismantle,
      netif_rx() does not have to check dev->flags & IFF_UP
      
      Virtual drivers do not have this guarantee, and must
      therefore make the check themselves.
      
      Otherwise we risk use-after-free and/or crashes.
      
      Fixes: d342894c ("vxlan: virtual extensible lan")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      59cbf56f
    • Eric Dumazet's avatar
      net/x25: fix use-after-free in x25_device_event() · 95d6ebd5
      Eric Dumazet authored
      In case of failure x25_connect() does a x25_neigh_put(x25->neighbour)
      but forgets to clear x25->neighbour pointer, thus triggering use-after-free.
      
      Since the socket is visible in x25_list, we need to hold x25_list_lock
      to protect the operation.
      
      syzbot report :
      
      BUG: KASAN: use-after-free in x25_kill_by_device net/x25/af_x25.c:217 [inline]
      BUG: KASAN: use-after-free in x25_device_event+0x296/0x2b0 net/x25/af_x25.c:252
      Read of size 8 at addr ffff8880a030edd0 by task syz-executor003/7854
      
      CPU: 0 PID: 7854 Comm: syz-executor003 Not tainted 5.0.0+ #97
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x172/0x1f0 lib/dump_stack.c:113
       print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
       kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
       __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:135
       x25_kill_by_device net/x25/af_x25.c:217 [inline]
       x25_device_event+0x296/0x2b0 net/x25/af_x25.c:252
       notifier_call_chain+0xc7/0x240 kernel/notifier.c:93
       __raw_notifier_call_chain kernel/notifier.c:394 [inline]
       raw_notifier_call_chain+0x2e/0x40 kernel/notifier.c:401
       call_netdevice_notifiers_info+0x3f/0x90 net/core/dev.c:1739
       call_netdevice_notifiers_extack net/core/dev.c:1751 [inline]
       call_netdevice_notifiers net/core/dev.c:1765 [inline]
       __dev_notify_flags+0x1e9/0x2c0 net/core/dev.c:7607
       dev_change_flags+0x10d/0x170 net/core/dev.c:7643
       dev_ifsioc+0x2b0/0x940 net/core/dev_ioctl.c:237
       dev_ioctl+0x1b8/0xc70 net/core/dev_ioctl.c:488
       sock_do_ioctl+0x1bd/0x300 net/socket.c:995
       sock_ioctl+0x32b/0x610 net/socket.c:1096
       vfs_ioctl fs/ioctl.c:46 [inline]
       file_ioctl fs/ioctl.c:509 [inline]
       do_vfs_ioctl+0xd6e/0x1390 fs/ioctl.c:696
       ksys_ioctl+0xab/0xd0 fs/ioctl.c:713
       __do_sys_ioctl fs/ioctl.c:720 [inline]
       __se_sys_ioctl fs/ioctl.c:718 [inline]
       __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718
       do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x4467c9
      Code: e8 0c e8 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 5b 07 fc ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007fdbea222d98 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
      RAX: ffffffffffffffda RBX: 00000000006dbc58 RCX: 00000000004467c9
      RDX: 0000000020000340 RSI: 0000000000008914 RDI: 0000000000000003
      RBP: 00000000006dbc50 R08: 00007fdbea223700 R09: 0000000000000000
      R10: 00007fdbea223700 R11: 0000000000000246 R12: 00000000006dbc5c
      R13: 6000030030626669 R14: 0000000000000000 R15: 0000000030626669
      
      Allocated by task 7843:
       save_stack+0x45/0xd0 mm/kasan/common.c:73
       set_track mm/kasan/common.c:85 [inline]
       __kasan_kmalloc mm/kasan/common.c:495 [inline]
       __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:468
       kasan_kmalloc+0x9/0x10 mm/kasan/common.c:509
       kmem_cache_alloc_trace+0x151/0x760 mm/slab.c:3615
       kmalloc include/linux/slab.h:545 [inline]
       x25_link_device_up+0x46/0x3f0 net/x25/x25_link.c:249
       x25_device_event+0x116/0x2b0 net/x25/af_x25.c:242
       notifier_call_chain+0xc7/0x240 kernel/notifier.c:93
       __raw_notifier_call_chain kernel/notifier.c:394 [inline]
       raw_notifier_call_chain+0x2e/0x40 kernel/notifier.c:401
       call_netdevice_notifiers_info+0x3f/0x90 net/core/dev.c:1739
       call_netdevice_notifiers_extack net/core/dev.c:1751 [inline]
       call_netdevice_notifiers net/core/dev.c:1765 [inline]
       __dev_notify_flags+0x121/0x2c0 net/core/dev.c:7605
       dev_change_flags+0x10d/0x170 net/core/dev.c:7643
       dev_ifsioc+0x2b0/0x940 net/core/dev_ioctl.c:237
       dev_ioctl+0x1b8/0xc70 net/core/dev_ioctl.c:488
       sock_do_ioctl+0x1bd/0x300 net/socket.c:995
       sock_ioctl+0x32b/0x610 net/socket.c:1096
       vfs_ioctl fs/ioctl.c:46 [inline]
       file_ioctl fs/ioctl.c:509 [inline]
       do_vfs_ioctl+0xd6e/0x1390 fs/ioctl.c:696
       ksys_ioctl+0xab/0xd0 fs/ioctl.c:713
       __do_sys_ioctl fs/ioctl.c:720 [inline]
       __se_sys_ioctl fs/ioctl.c:718 [inline]
       __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718
       do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Freed by task 7865:
       save_stack+0x45/0xd0 mm/kasan/common.c:73
       set_track mm/kasan/common.c:85 [inline]
       __kasan_slab_free+0x102/0x150 mm/kasan/common.c:457
       kasan_slab_free+0xe/0x10 mm/kasan/common.c:465
       __cache_free mm/slab.c:3494 [inline]
       kfree+0xcf/0x230 mm/slab.c:3811
       x25_neigh_put include/net/x25.h:253 [inline]
       x25_connect+0x8d8/0xde0 net/x25/af_x25.c:824
       __sys_connect+0x266/0x330 net/socket.c:1685
       __do_sys_connect net/socket.c:1696 [inline]
       __se_sys_connect net/socket.c:1693 [inline]
       __x64_sys_connect+0x73/0xb0 net/socket.c:1693
       do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      The buggy address belongs to the object at ffff8880a030edc0
       which belongs to the cache kmalloc-256 of size 256
      The buggy address is located 16 bytes inside of
       256-byte region [ffff8880a030edc0, ffff8880a030eec0)
      The buggy address belongs to the page:
      page:ffffea000280c380 count:1 mapcount:0 mapping:ffff88812c3f07c0 index:0x0
      flags: 0x1fffc0000000200(slab)
      raw: 01fffc0000000200 ffffea0002806788 ffffea00027f0188 ffff88812c3f07c0
      raw: 0000000000000000 ffff8880a030e000 000000010000000c 0000000000000000
      page dumped because: kasan: bad access detected
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: syzbot+04babcefcd396fabec37@syzkaller.appspotmail.com
      Cc: andrew hendry <andrew.hendry@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      95d6ebd5
    • Kangjie Lu's avatar
      isdn: mISDNinfineon: fix potential NULL pointer dereference · d721fe99
      Kangjie Lu authored
      In case ioremap fails, the fix returns -ENOMEM to avoid NULL
      pointer dereference.
      Signed-off-by: default avatarKangjie Lu <kjlu@umn.edu>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d721fe99
    • Shiju Jose's avatar
      net: hns3: fix to stop multiple HNS reset due to the AER changes · 69b51bbb
      Shiju Jose authored
      The commit bfcb79fc
      ("PCI/ERR: Run error recovery callbacks for all affected devices")
      affected the non-fatal error recovery logic for the HNS and RDMA devices.
      This is because each HNS PF under PCIe bus receive callbacks
      from the AER driver when an error is reported for one of the PF.
      This causes unwanted PF resets because
      the HNS decides which PF to reset based on the reset type set.
      The HNS error handling code sets the reset type based on the hw error
      type detected.
      
      This patch provides fix for the above issue for the recovery of
      the hw errors in the HNS and RDMA devices.
      
      This patch needs backporting to the kernel v5.0+
      
      Fixes: 332fbf57 ("net: hns3: add handling of hw ras errors using new set of commands")
      Reported-by: default avatarXiaofei Tan <tanxiaofei@huawei.com>
      Signed-off-by: default avatarShiju Jose <shiju.jose@huawei.com>
      Signed-off-by: default avatarHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      69b51bbb
    • Eric Dumazet's avatar
      ip: fix ip_mc_may_pull() return value · 083b78a9
      Eric Dumazet authored
      ip_mc_may_pull() must return 0 if there is a problem, not an errno.
      
      syzbot reported :
      
      BUG: KASAN: use-after-free in br_ip4_multicast_igmp3_report net/bridge/br_multicast.c:947 [inline]
      BUG: KASAN: use-after-free in br_multicast_ipv4_rcv net/bridge/br_multicast.c:1631 [inline]
      BUG: KASAN: use-after-free in br_multicast_rcv+0x3cd8/0x4440 net/bridge/br_multicast.c:1741
      Read of size 4 at addr ffff88820a4084ee by task syz-executor.2/11183
      
      CPU: 1 PID: 11183 Comm: syz-executor.2 Not tainted 5.0.0+ #14
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x172/0x1f0 lib/dump_stack.c:113
       print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
       kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
       __asan_report_load4_noabort+0x14/0x20 mm/kasan/generic_report.c:131
       br_ip4_multicast_igmp3_report net/bridge/br_multicast.c:947 [inline]
       br_multicast_ipv4_rcv net/bridge/br_multicast.c:1631 [inline]
       br_multicast_rcv+0x3cd8/0x4440 net/bridge/br_multicast.c:1741
       br_handle_frame_finish+0xa3a/0x14c0 net/bridge/br_input.c:108
       br_nf_hook_thresh+0x2ec/0x380 net/bridge/br_netfilter_hooks.c:1005
       br_nf_pre_routing_finish+0x8e2/0x1750 net/bridge/br_netfilter_hooks.c:410
       NF_HOOK include/linux/netfilter.h:289 [inline]
       NF_HOOK include/linux/netfilter.h:283 [inline]
       br_nf_pre_routing+0x7e7/0x13a0 net/bridge/br_netfilter_hooks.c:506
       nf_hook_entry_hookfn include/linux/netfilter.h:119 [inline]
       nf_hook_slow+0xbf/0x1f0 net/netfilter/core.c:511
       nf_hook include/linux/netfilter.h:244 [inline]
       NF_HOOK include/linux/netfilter.h:287 [inline]
       br_handle_frame+0x95b/0x1450 net/bridge/br_input.c:305
       __netif_receive_skb_core+0xa96/0x3040 net/core/dev.c:4902
       __netif_receive_skb_one_core+0xa8/0x1a0 net/core/dev.c:4971
       __netif_receive_skb+0x2c/0x1c0 net/core/dev.c:5083
       netif_receive_skb_internal+0x117/0x660 net/core/dev.c:5186
       netif_receive_skb+0x6e/0x5a0 net/core/dev.c:5261
      
      Fixes: ba5ea614 ("bridge: simplify ip_mc_check_igmp() and ipv6_mc_check_mld() calls")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Cc: Linus Lüssing <linus.luessing@c0d3.blue>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      083b78a9
    • Guillaume Nault's avatar
      net: keep refcount warning in reqsk_free() · 1039c6e1
      Guillaume Nault authored
      As Eric Dumazet said, "We do not have a way to tell if the req was ever
      inserted in a hash table, so better play safe.".
      Let's remove this comment, so that nobody will be tempted to drop the
      WARN_ON_ONCE() line.
      Signed-off-by: default avatarGuillaume Nault <gnault@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1039c6e1
  3. 09 Mar, 2019 5 commits
    • Nathan Chancellor's avatar
      net: stmmac: Avoid one more sometimes uninitialized Clang warning · 1f5d861f
      Nathan Chancellor authored
      When building with -Wsometimes-uninitialized, Clang warns:
      
      drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c:111:2: error: variable
      'ns' is used uninitialized whenever 'if' condition is false
      [-Werror,-Wsometimes-uninitialized]
      drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c:111:2: error: variable
      'ns' is used uninitialized whenever '&&' condition is false
      [-Werror,-Wsometimes-uninitialized]
      
      Clang is concerned with the use of stmmac_do_void_callback (which
      stmmac_get_systime wraps), as it may fail to initialize these values if
      the if condition was ever false (meaning the callback doesn't exist).
      It's not wrong because the callback is what initializes ns. While it's
      unlikely that the callback is going to disappear at some point and make
      that condition false, we can easily avoid this warning by zero
      initializing the variable.
      
      Link: https://github.com/ClangBuiltLinux/linux/issues/384
      Fixes: df103170 ("net: stmmac: Avoid sometimes uninitialized Clang warnings")
      Suggested-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Reviewed-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1f5d861f
    • Andrew Lunn's avatar
      net: dsa: mv88e6xxx: Set correct interface mode for CPU/DSA ports · 7cbbee05
      Andrew Lunn authored
      By default, the switch driver is expected to configure CPU and DSA
      ports to their maximum speed. For the 6341 and 6390 families, the
      ports interface mode has to be configured as well. The 6390X range
      support 10G ports using XAUI, while the 6341 and 6390 supports
      2500BaseX, as their maximum speed.
      
      Fixes: 787799a9 ("net: dsa: mv88e6xxx: Default ports 9/10 6390X CMODE to 1000BaseX")
      Signed-off-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7cbbee05
    • David Howells's avatar
      rxrpc: Fix client call queueing, waiting for channel · 69ffaebb
      David Howells authored
      rxrpc_get_client_conn() adds a new call to the front of the waiting_calls
      queue if the connection it's going to use already exists.  This is bad as
      it allows calls to get starved out.
      
      Fix this by adding to the tail instead.
      
      Also change the other enqueue point in the same function to put it on the
      front (ie. when we have a new connection).  This makes the point that in
      the case of a new connection the new call goes at the front (though it
      doesn't actually matter since the queue should be unoccupied).
      
      Fixes: 45025bce ("rxrpc: Improve management and caching of client connection objects")
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Reviewed-by: default avatarMarc Dionne <marc.dionne@auristor.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      69ffaebb
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf · c3ad3eca
      David S. Miller authored
      Daniel Borkmann says:
      
      ====================
      pull-request: bpf 2019-03-09
      
      The following pull-request contains BPF updates for your *net* tree.
      
      The main changes are:
      
      1) Fix a crash in AF_XDP's xsk_diag_put_ring() which was passing
         wrong queue argument, from Eric.
      
      2) Fix a regression due to wrong test for TCP GSO packets used in
         various BPF helpers like NAT64, from Willem.
      
      3) Fix a sk_msg strparser warning which asserts that strparser must
         be stopped first, from Jakub.
      
      4) Fix rejection of invalid options/bind flags in AF_XDP, from Björn.
      
      5) Fix GSO in bpf_lwt_push_ip_encap() which must properly set inner
         headers and inner protocol, from Peter.
      
      6) Fix a libbpf leak when kernel does not support BTF, from Nikita.
      
      7) Various BPF selftest and libbpf build fixes to make out-of-tree
         compilation work and to properly resolve dependencies via fixdep
         target, from Stanislav.
      
      8) Fix rejection of invalid ldimm64 imm field, from Daniel.
      
      9) Fix bpf stats sysctl compile warning of unused helper function
         proc_dointvec_minmax_bpf_stats() under some configs, from Arnd.
      
      10) Fix couple of warnings about using plain integer as NULL, from Bo.
      
      11) Fix some BPF sample spelling mistakes, from Colin.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c3ad3eca
    • Guillaume Nault's avatar
      tcp: handle inet_csk_reqsk_queue_add() failures · 9d3e1368
      Guillaume Nault authored
      Commit 7716682c ("tcp/dccp: fix another race at listener
      dismantle") let inet_csk_reqsk_queue_add() fail, and adjusted
      {tcp,dccp}_check_req() accordingly. However, TFO and syncookies
      weren't modified, thus leaking allocated resources on error.
      
      Contrary to tcp_check_req(), in both syncookies and TFO cases,
      we need to drop the request socket. Also, since the child socket is
      created with inet_csk_clone_lock(), we have to unlock it and drop an
      extra reference (->sk_refcount is initially set to 2 and
      inet_csk_reqsk_queue_add() drops only one ref).
      
      For TFO, we also need to revert the work done by tcp_try_fastopen()
      (with reqsk_fastopen_remove()).
      
      Fixes: 7716682c ("tcp/dccp: fix another race at listener dismantle")
      Signed-off-by: default avatarGuillaume Nault <gnault@redhat.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9d3e1368
  4. 08 Mar, 2019 14 commits
    • Nathan Chancellor's avatar
      net: ethernet: sun: Zero initialize class in default case in niu_add_ethtool_tcam_entry · 09073525
      Nathan Chancellor authored
      When building with -Wsometimes-uninitialized, Clang warns:
      
      drivers/net/ethernet/sun/niu.c:7466:5: warning: variable 'class' is used
      uninitialized whenever switch default is taken
      [-Wsometimes-uninitialized]
      
      The default case can never happen because i can only be 0 to 3
      (NIU_L3_PROG_CLS is defined as 4). To make this clear to Clang,
      just zero initialize class in the default case (use the macro
      CLASS_CODE_UNRECOG to make it clear this shouldn't happen).
      
      Link: https://github.com/ClangBuiltLinux/linux/issues/403Signed-off-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Reviewed-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      09073525
    • Matthew Whitehead's avatar
      8139too : Add support for U.S. Robotics USR997901A 10/100 Cardbus NIC · 580411d0
      Matthew Whitehead authored
      Add PCI vendor and device identifier for U.S. Robotics USR997901A
      10/100 Cardbus NIC. Tested on real hardware.
      Signed-off-by: default avatarMatthew Whitehead <tedheadster@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      580411d0
    • Eric Dumazet's avatar
      fou, fou6: avoid uninit-value in gue_err() and gue6_err() · 5355ed63
      Eric Dumazet authored
      My prior commit missed the fact that these functions
      were using udp_hdr() (aka skb_transport_header())
      to get access to GUE header.
      
      Since pskb_transport_may_pull() does not exist yet, we have to add
      transport_offset to our pskb_may_pull() calls.
      
      BUG: KMSAN: uninit-value in gue_err+0x514/0xfa0 net/ipv4/fou.c:1032
      CPU: 1 PID: 10648 Comm: syz-executor.1 Not tainted 5.0.0+ #11
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       <IRQ>
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x173/0x1d0 lib/dump_stack.c:113
       kmsan_report+0x12e/0x2a0 mm/kmsan/kmsan.c:600
       __msan_warning+0x82/0xf0 mm/kmsan/kmsan_instr.c:313
       gue_err+0x514/0xfa0 net/ipv4/fou.c:1032
       __udp4_lib_err_encap_no_sk net/ipv4/udp.c:571 [inline]
       __udp4_lib_err_encap net/ipv4/udp.c:626 [inline]
       __udp4_lib_err+0x12e6/0x1d40 net/ipv4/udp.c:665
       udp_err+0x74/0x90 net/ipv4/udp.c:737
       icmp_socket_deliver net/ipv4/icmp.c:767 [inline]
       icmp_unreach+0xb65/0x1070 net/ipv4/icmp.c:884
       icmp_rcv+0x11a1/0x1950 net/ipv4/icmp.c:1066
       ip_protocol_deliver_rcu+0x584/0xbb0 net/ipv4/ip_input.c:208
       ip_local_deliver_finish net/ipv4/ip_input.c:234 [inline]
       NF_HOOK include/linux/netfilter.h:289 [inline]
       ip_local_deliver+0x624/0x7b0 net/ipv4/ip_input.c:255
       dst_input include/net/dst.h:450 [inline]
       ip_rcv_finish net/ipv4/ip_input.c:414 [inline]
       NF_HOOK include/linux/netfilter.h:289 [inline]
       ip_rcv+0x6bd/0x740 net/ipv4/ip_input.c:524
       __netif_receive_skb_one_core net/core/dev.c:4973 [inline]
       __netif_receive_skb net/core/dev.c:5083 [inline]
       process_backlog+0x756/0x10e0 net/core/dev.c:5923
       napi_poll net/core/dev.c:6346 [inline]
       net_rx_action+0x78b/0x1a60 net/core/dev.c:6412
       __do_softirq+0x53f/0x93a kernel/softirq.c:293
       invoke_softirq kernel/softirq.c:375 [inline]
       irq_exit+0x214/0x250 kernel/softirq.c:416
       exiting_irq+0xe/0x10 arch/x86/include/asm/apic.h:536
       smp_apic_timer_interrupt+0x48/0x70 arch/x86/kernel/apic/apic.c:1064
       apic_timer_interrupt+0x2e/0x40 arch/x86/entry/entry_64.S:814
       </IRQ>
      RIP: 0010:finish_lock_switch+0x2b/0x40 kernel/sched/core.c:2597
      Code: 48 89 e5 53 48 89 fb e8 63 e7 95 00 8b b8 88 0c 00 00 48 8b 00 48 85 c0 75 12 48 89 df e8 dd db 95 00 c6 00 00 c6 03 00 fb 5b <5d> c3 e8 4e e6 95 00 eb e7 66 90 66 2e 0f 1f 84 00 00 00 00 00 55
      RSP: 0018:ffff888081a0fc80 EFLAGS: 00000296 ORIG_RAX: ffffffffffffff13
      RAX: ffff88821fd6bd80 RBX: ffff888027898000 RCX: ccccccccccccd000
      RDX: ffff88821fca8d80 RSI: ffff888000000000 RDI: 00000000000004a0
      RBP: ffff888081a0fc80 R08: 0000000000000002 R09: ffff888081a0fb08
      R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001
      R13: ffff88811130e388 R14: ffff88811130da00 R15: ffff88812fdb7d80
       finish_task_switch+0xfc/0x2d0 kernel/sched/core.c:2698
       context_switch kernel/sched/core.c:2851 [inline]
       __schedule+0x6cc/0x800 kernel/sched/core.c:3491
       schedule+0x15b/0x240 kernel/sched/core.c:3535
       freezable_schedule include/linux/freezer.h:172 [inline]
       do_nanosleep+0x2ba/0x980 kernel/time/hrtimer.c:1679
       hrtimer_nanosleep kernel/time/hrtimer.c:1733 [inline]
       __do_sys_nanosleep kernel/time/hrtimer.c:1767 [inline]
       __se_sys_nanosleep+0x746/0x960 kernel/time/hrtimer.c:1754
       __x64_sys_nanosleep+0x3e/0x60 kernel/time/hrtimer.c:1754
       do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
       entry_SYSCALL_64_after_hwframe+0x63/0xe7
      RIP: 0033:0x4855a0
      Code: 00 00 48 c7 c0 d4 ff ff ff 64 c7 00 16 00 00 00 31 c0 eb be 66 0f 1f 44 00 00 83 3d b1 11 5d 00 00 75 14 b8 23 00 00 00 0f 05 <48> 3d 01 f0 ff ff 0f 83 04 e2 f8 ff c3 48 83 ec 08 e8 3a 55 fd ff
      RSP: 002b:0000000000a4fd58 EFLAGS: 00000246 ORIG_RAX: 0000000000000023
      RAX: ffffffffffffffda RBX: 0000000000085780 RCX: 00000000004855a0
      RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000a4fd60
      RBP: 00000000000007ec R08: 0000000000000001 R09: 0000000000ceb940
      R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000008
      R13: 0000000000a4fdb0 R14: 0000000000085711 R15: 0000000000a4fdc0
      
      Uninit was created at:
       kmsan_save_stack_with_flags mm/kmsan/kmsan.c:205 [inline]
       kmsan_internal_poison_shadow+0x92/0x150 mm/kmsan/kmsan.c:159
       kmsan_kmalloc+0xa6/0x130 mm/kmsan/kmsan_hooks.c:176
       kmsan_slab_alloc+0xe/0x10 mm/kmsan/kmsan_hooks.c:185
       slab_post_alloc_hook mm/slab.h:445 [inline]
       slab_alloc_node mm/slub.c:2773 [inline]
       __kmalloc_node_track_caller+0xe9e/0xff0 mm/slub.c:4398
       __kmalloc_reserve net/core/skbuff.c:140 [inline]
       __alloc_skb+0x309/0xa20 net/core/skbuff.c:208
       alloc_skb include/linux/skbuff.h:1012 [inline]
       alloc_skb_with_frags+0x186/0xa60 net/core/skbuff.c:5287
       sock_alloc_send_pskb+0xafd/0x10a0 net/core/sock.c:2091
       sock_alloc_send_skb+0xca/0xe0 net/core/sock.c:2108
       __ip_append_data+0x34cd/0x5000 net/ipv4/ip_output.c:998
       ip_append_data+0x324/0x480 net/ipv4/ip_output.c:1220
       icmp_push_reply+0x23d/0x7e0 net/ipv4/icmp.c:375
       __icmp_send+0x2ea3/0x30f0 net/ipv4/icmp.c:737
       icmp_send include/net/icmp.h:47 [inline]
       ipv4_link_failure+0x6d/0x230 net/ipv4/route.c:1190
       dst_link_failure include/net/dst.h:427 [inline]
       arp_error_report+0x106/0x1a0 net/ipv4/arp.c:297
       neigh_invalidate+0x359/0x8e0 net/core/neighbour.c:992
       neigh_timer_handler+0xdf2/0x1280 net/core/neighbour.c:1078
       call_timer_fn+0x285/0x600 kernel/time/timer.c:1325
       expire_timers kernel/time/timer.c:1362 [inline]
       __run_timers+0xdb4/0x11d0 kernel/time/timer.c:1681
       run_timer_softirq+0x2e/0x50 kernel/time/timer.c:1694
       __do_softirq+0x53f/0x93a kernel/softirq.c:293
      
      Fixes: 26fc181e ("fou, fou6: do not assume linear skbs")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Cc: Stefano Brivio <sbrivio@redhat.com>
      Cc: Sabrina Dubroca <sd@queasysnail.net>
      Acked-by: default avatarStefano Brivio <sbrivio@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5355ed63
    • Vlad Buslov's avatar
      net: sched: fix potential use-after-free in __tcf_chain_put() · b62989fc
      Vlad Buslov authored
      When used with unlocked classifier that have filters attached to actions
      with goto chain, __tcf_chain_put() for last non action reference can race
      with calls to same function from action cleanup code that releases last
      action reference. In this case action cleanup handler could free the chain
      if it executes after all references to chain were released, but before all
      concurrent users finished using it. Modify __tcf_chain_put() to only access
      tcf_chain fields when holding block->lock. Remove local variables that were
      used to cache some tcf_chain fields and are no longer needed because their
      values can now be obtained directly from chain under block->lock
      protection.
      
      Fixes: 726d0612 ("net: sched: prevent insertion of new classifiers during chain flush")
      Signed-off-by: default avatarVlad Buslov <vladbu@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b62989fc
    • Arnd Bergmann's avatar
      vhost: silence an unused-variable warning · 81bf7bbe
      Arnd Bergmann authored
      On some architectures, the MMU can be disabled, leading to access_ok()
      becoming an empty macro that does not evaluate its size argument,
      which in turn produces an unused-variable warning:
      
      drivers/vhost/vhost.c:1191:9: error: unused variable 's' [-Werror,-Wunused-variable]
              size_t s = vhost_has_feature(vq, VIRTIO_RING_F_EVENT_IDX) ? 2 : 0;
      
      Mark the variable as __maybe_unused to shut up that warning.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarJason Wang <jasowang@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      81bf7bbe
    • Adalbert Lazăr's avatar
      vsock/virtio: fix kernel panic from virtio_transport_reset_no_sock · 4c404ce2
      Adalbert Lazăr authored
      Previous to commit 22b5c0b6 ("vsock/virtio: fix kernel panic
      after device hot-unplug"), vsock_core_init() was called from
      virtio_vsock_probe(). Now, virtio_transport_reset_no_sock() can be called
      before vsock_core_init() has the chance to run.
      
      [Wed Feb 27 14:17:09 2019] BUG: unable to handle kernel NULL pointer dereference at 0000000000000110
      [Wed Feb 27 14:17:09 2019] #PF error: [normal kernel read fault]
      [Wed Feb 27 14:17:09 2019] PGD 0 P4D 0
      [Wed Feb 27 14:17:09 2019] Oops: 0000 [#1] SMP PTI
      [Wed Feb 27 14:17:09 2019] CPU: 3 PID: 59 Comm: kworker/3:1 Not tainted 5.0.0-rc7-390-generic-hvi #390
      [Wed Feb 27 14:17:09 2019] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
      [Wed Feb 27 14:17:09 2019] Workqueue: virtio_vsock virtio_transport_rx_work [vmw_vsock_virtio_transport]
      [Wed Feb 27 14:17:09 2019] RIP: 0010:virtio_transport_reset_no_sock+0x8c/0xc0 [vmw_vsock_virtio_transport_common]
      [Wed Feb 27 14:17:09 2019] Code: 35 8b 4f 14 48 8b 57 08 31 f6 44 8b 4f 10 44 8b 07 48 8d 7d c8 e8 84 f8 ff ff 48 85 c0 48 89 c3 74 2a e8 f7 31 03 00 48 89 df <48> 8b 80 10 01 00 00 e8 68 fb 69 ed 48 8b 75 f0 65 48 33 34 25 28
      [Wed Feb 27 14:17:09 2019] RSP: 0018:ffffb42701ab7d40 EFLAGS: 00010282
      [Wed Feb 27 14:17:09 2019] RAX: 0000000000000000 RBX: ffff9d79637ee080 RCX: 0000000000000003
      [Wed Feb 27 14:17:09 2019] RDX: 0000000000000001 RSI: 0000000000000002 RDI: ffff9d79637ee080
      [Wed Feb 27 14:17:09 2019] RBP: ffffb42701ab7d78 R08: ffff9d796fae70e0 R09: ffff9d796f403500
      [Wed Feb 27 14:17:09 2019] R10: ffffb42701ab7d90 R11: 0000000000000000 R12: ffff9d7969d09240
      [Wed Feb 27 14:17:09 2019] R13: ffff9d79624e6840 R14: ffff9d7969d09318 R15: ffff9d796d48ff80
      [Wed Feb 27 14:17:09 2019] FS:  0000000000000000(0000) GS:ffff9d796fac0000(0000) knlGS:0000000000000000
      [Wed Feb 27 14:17:09 2019] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [Wed Feb 27 14:17:09 2019] CR2: 0000000000000110 CR3: 0000000427f22000 CR4: 00000000000006e0
      [Wed Feb 27 14:17:09 2019] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [Wed Feb 27 14:17:09 2019] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [Wed Feb 27 14:17:09 2019] Call Trace:
      [Wed Feb 27 14:17:09 2019]  virtio_transport_recv_pkt+0x63/0x820 [vmw_vsock_virtio_transport_common]
      [Wed Feb 27 14:17:09 2019]  ? kfree+0x17e/0x190
      [Wed Feb 27 14:17:09 2019]  ? detach_buf_split+0x145/0x160
      [Wed Feb 27 14:17:09 2019]  ? __switch_to_asm+0x40/0x70
      [Wed Feb 27 14:17:09 2019]  virtio_transport_rx_work+0xa0/0x106 [vmw_vsock_virtio_transport]
      [Wed Feb 27 14:17:09 2019] NET: Registered protocol family 40
      [Wed Feb 27 14:17:09 2019]  process_one_work+0x167/0x410
      [Wed Feb 27 14:17:09 2019]  worker_thread+0x4d/0x460
      [Wed Feb 27 14:17:09 2019]  kthread+0x105/0x140
      [Wed Feb 27 14:17:09 2019]  ? rescuer_thread+0x360/0x360
      [Wed Feb 27 14:17:09 2019]  ? kthread_destroy_worker+0x50/0x50
      [Wed Feb 27 14:17:09 2019]  ret_from_fork+0x35/0x40
      [Wed Feb 27 14:17:09 2019] Modules linked in: vmw_vsock_virtio_transport vmw_vsock_virtio_transport_common input_leds vsock serio_raw i2c_piix4 mac_hid qemu_fw_cfg autofs4 cirrus ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops virtio_net psmouse drm net_failover pata_acpi virtio_blk failover floppy
      
      Fixes: 22b5c0b6 ("vsock/virtio: fix kernel panic after device hot-unplug")
      Reported-by: default avatarAlexandru Herghelegiu <aherghelegiu@bitdefender.com>
      Signed-off-by: default avatarAdalbert Lazăr <alazar@bitdefender.com>
      Co-developed-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Reviewed-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Reviewed-by: default avatarStefano Garzarella <sgarzare@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4c404ce2
    • Li RongQing's avatar
      connector: fix unsafe usage of ->real_parent · 6d2b0f02
      Li RongQing authored
      proc_exit_connector() uses ->real_parent lockless. This is not
      safe that its parent can go away at any moment, so use RCU to
      protect it, and ensure that this task is not released.
      
      [  747.624551] ==================================================================
      [  747.632946] BUG: KASAN: use-after-free in proc_exit_connector+0x1f7/0x310
      [  747.640686] Read of size 4 at addr ffff88a0276988e0 by task sshd/2882
      [  747.648032]
      [  747.649804] CPU: 11 PID: 2882 Comm: sshd Tainted: G            E     4.19.26-rc2 #11
      [  747.658629] Hardware name: IBM x3550M4 -[7914OFV]-/00AM544, BIOS -[D7E142BUS-1.71]- 07/31/2014
      [  747.668419] Call Trace:
      [  747.671269]  dump_stack+0xf0/0x19b
      [  747.675186]  ? show_regs_print_info+0x5/0x5
      [  747.679988]  ? kmsg_dump_rewind_nolock+0x59/0x59
      [  747.685302]  print_address_description+0x6a/0x270
      [  747.691162]  kasan_report+0x258/0x380
      [  747.695835]  ? proc_exit_connector+0x1f7/0x310
      [  747.701402]  proc_exit_connector+0x1f7/0x310
      [  747.706767]  ? proc_coredump_connector+0x2d0/0x2d0
      [  747.712715]  ? _raw_write_unlock_irq+0x29/0x50
      [  747.718270]  ? _raw_write_unlock_irq+0x29/0x50
      [  747.723820]  ? ___preempt_schedule+0x16/0x18
      [  747.729193]  ? ___preempt_schedule+0x16/0x18
      [  747.734574]  do_exit+0xa11/0x14f0
      [  747.738880]  ? mm_update_next_owner+0x590/0x590
      [  747.744525]  ? debug_show_all_locks+0x3c0/0x3c0
      [  747.761448]  ? ktime_get_coarse_real_ts64+0xeb/0x1c0
      [  747.767589]  ? lockdep_hardirqs_on+0x1a6/0x290
      [  747.773154]  ? check_chain_key+0x139/0x1f0
      [  747.778345]  ? check_flags.part.35+0x240/0x240
      [  747.783908]  ? __lock_acquire+0x2300/0x2300
      [  747.789171]  ? _raw_spin_unlock_irqrestore+0x59/0x70
      [  747.795316]  ? _raw_spin_unlock_irqrestore+0x59/0x70
      [  747.801457]  ? do_raw_spin_unlock+0x10f/0x1e0
      [  747.806914]  ? do_raw_spin_trylock+0x120/0x120
      [  747.812481]  ? preempt_count_sub+0x14/0xc0
      [  747.817645]  ? _raw_spin_unlock+0x2e/0x50
      [  747.822708]  ? __handle_mm_fault+0x12db/0x1fa0
      [  747.828367]  ? __pmd_alloc+0x2d0/0x2d0
      [  747.833143]  ? check_noncircular+0x50/0x50
      [  747.838309]  ? match_held_lock+0x7f/0x340
      [  747.843380]  ? check_noncircular+0x50/0x50
      [  747.848561]  ? handle_mm_fault+0x21a/0x5f0
      [  747.853730]  ? check_flags.part.35+0x240/0x240
      [  747.859290]  ? check_chain_key+0x139/0x1f0
      [  747.864474]  ? __do_page_fault+0x40f/0x760
      [  747.869655]  ? __audit_syscall_entry+0x4b/0x1f0
      [  747.875319]  ? syscall_trace_enter+0x1d5/0x7b0
      [  747.880877]  ? trace_raw_output_preemptirq_template+0x90/0x90
      [  747.887895]  ? trace_raw_output_sys_exit+0x80/0x80
      [  747.893860]  ? up_read+0x3b/0x90
      [  747.898142]  ? stop_critical_timings+0x260/0x260
      [  747.903909]  do_group_exit+0xe0/0x1c0
      [  747.908591]  ? __x64_sys_exit+0x30/0x30
      [  747.913460]  ? trace_raw_output_preemptirq_template+0x90/0x90
      [  747.920485]  ? tracer_hardirqs_on+0x270/0x270
      [  747.925956]  __x64_sys_exit_group+0x28/0x30
      [  747.931214]  do_syscall_64+0x117/0x400
      [  747.935988]  ? syscall_return_slowpath+0x2f0/0x2f0
      [  747.941931]  ? trace_hardirqs_off_thunk+0x1a/0x1c
      [  747.947788]  ? trace_hardirqs_on_caller+0x1d0/0x1d0
      [  747.953838]  ? lockdep_sys_exit+0x16/0x8e
      [  747.958915]  ? trace_hardirqs_off_thunk+0x1a/0x1c
      [  747.964784]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      [  747.971021] RIP: 0033:0x7f572f154c68
      [  747.975606] Code: Bad RIP value.
      [  747.979791] RSP: 002b:00007ffed2dfaa58 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
      [  747.989324] RAX: ffffffffffffffda RBX: 00007f572f431840 RCX: 00007f572f154c68
      [  747.997910] RDX: 0000000000000001 RSI: 000000000000003c RDI: 0000000000000001
      [  748.006495] RBP: 0000000000000001 R08: 00000000000000e7 R09: fffffffffffffee0
      [  748.015079] R10: 00007f572f4387e8 R11: 0000000000000246 R12: 00007f572f431840
      [  748.023664] R13: 000055a7f90f2c50 R14: 000055a7f96e2310 R15: 000055a7f96e2310
      [  748.032287]
      [  748.034509] Allocated by task 2300:
      [  748.038982]  kasan_kmalloc+0xa0/0xd0
      [  748.043562]  kmem_cache_alloc_node+0xf5/0x2e0
      [  748.049018]  copy_process+0x1781/0x4790
      [  748.053884]  _do_fork+0x166/0x9a0
      [  748.058163]  do_syscall_64+0x117/0x400
      [  748.062943]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      [  748.069180]
      [  748.071405] Freed by task 15395:
      [  748.075591]  __kasan_slab_free+0x130/0x180
      [  748.080752]  kmem_cache_free+0xc2/0x310
      [  748.085619]  free_task+0xea/0x130
      [  748.089901]  __put_task_struct+0x177/0x230
      [  748.095063]  finish_task_switch+0x51b/0x5d0
      [  748.100315]  __schedule+0x506/0xfa0
      [  748.104791]  schedule+0xca/0x260
      [  748.108978]  futex_wait_queue_me+0x27e/0x420
      [  748.114333]  futex_wait+0x251/0x550
      [  748.118814]  do_futex+0x75b/0xf80
      [  748.123097]  __x64_sys_futex+0x231/0x2a0
      [  748.128065]  do_syscall_64+0x117/0x400
      [  748.132835]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      [  748.139066]
      [  748.141289] The buggy address belongs to the object at ffff88a027698000
      [  748.141289]  which belongs to the cache task_struct of size 12160
      [  748.156589] The buggy address is located 2272 bytes inside of
      [  748.156589]  12160-byte region [ffff88a027698000, ffff88a02769af80)
      [  748.171114] The buggy address belongs to the page:
      [  748.177055] page:ffffea00809da600 count:1 mapcount:0 mapping:ffff888107d01e00 index:0x0 compound_mapcount: 0
      [  748.189136] flags: 0x57ffffc0008100(slab|head)
      [  748.194688] raw: 0057ffffc0008100 ffffea00809a3200 0000000300000003 ffff888107d01e00
      [  748.204424] raw: 0000000000000000 0000000000020002 00000001ffffffff 0000000000000000
      [  748.214146] page dumped because: kasan: bad access detected
      [  748.220976]
      [  748.223197] Memory state around the buggy address:
      [  748.229128]  ffff88a027698780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [  748.238271]  ffff88a027698800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [  748.247414] >ffff88a027698880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [  748.256564]                                                        ^
      [  748.264267]  ffff88a027698900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [  748.273493]  ffff88a027698980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [  748.282630] ==================================================================
      
      Fixes: b086ff87 ("connector: add parent pid and tgid to coredump and exit events")
      Signed-off-by: default avatarZhang Yu <zhangyu31@baidu.com>
      Signed-off-by: default avatarLi RongQing <lirongqing@baidu.com>
      Acked-by: default avatarEvgeniy Polyakov <zbr@ioremap.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6d2b0f02
    • Litao Jiao's avatar
      vxlan: do not need BH again in vxlan_cleanup() · f98ec788
      Litao Jiao authored
      vxlan_cleanup() is a timer callback, it is already
      and only running in BH context.
      Signed-off-by: default avatarLitao Jiao <jiaolitao@raisecom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f98ec788
    • Jian Shen's avatar
      net: hns3: add dma_rmb() for rx description · d394d33b
      Jian Shen authored
      HW can not guarantee complete write desc->rx.size, even though
      HNS3_RXD_VLD_B has been set. Driver needs to add dma_rmb()
      instruction to make sure desc->rx.size is always valid.
      
      Fixes: e5597095 ("net: hns3: Add handling of GRO Pkts not fully RX'ed in NAPI poll")
      Signed-off-by: default avatarJian Shen <shenjian15@huawei.com>
      Signed-off-by: default avatarHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d394d33b
    • Pedro Tammela's avatar
      net: add missing documentation in linux/skbuff.h · 161e6137
      Pedro Tammela authored
      This patch adds missing documentation for some inline functions on
      linux/skbuff.h. The patch is incomplete and a lot more can be added,
      just wondering if it's of interest of the netdev developers.
      
      Also fixed some whitespaces.
      Signed-off-by: default avatarPedro Tammela <pctammela@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      161e6137
    • Bo YU's avatar
      bpf: fix warning about using plain integer as NULL · 71b91a50
      Bo YU authored
      Sparse warning below:
      
      sudo make C=2 CF=-D__CHECK_ENDIAN__ M=net/bpf/
      CHECK   net/bpf//test_run.c
      net/bpf//test_run.c:19:77: warning: Using plain integer as NULL pointer
      ./include/linux/bpf-cgroup.h:295:77: warning: Using plain integer as NULL pointer
      
      Fixes: 8bad74f9 ("bpf: extend cgroup bpf core to allow multiple cgroup storage types")
      Acked-by: default avatarYonghong Song <yhs@fb.com>
      Signed-off-by: default avatarBo YU <tsu.yubo@gmail.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      71b91a50
    • Björn Töpel's avatar
      xsk: fix to reject invalid options in Tx descriptor · c57b557b
      Björn Töpel authored
      Passing a non-existing option in the options member of struct
      xdp_desc was, incorrectly, silently ignored. This patch addresses
      that behavior, and drops any Tx descriptor with non-existing options.
      
      We have examined existing user space code, and to our best knowledge,
      no one is relying on the current incorrect behavior. AF_XDP is still
      in its infancy, so from our perspective, the risk of breakage is very
      low, and addressing this problem now is important.
      
      Fixes: 35fcde7f ("xsk: support for Tx")
      Signed-off-by: default avatarBjörn Töpel <bjorn.topel@intel.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      c57b557b
    • Björn Töpel's avatar
      xsk: fix to reject invalid flags in xsk_bind · f54ba391
      Björn Töpel authored
      Passing a non-existing flag in the sxdp_flags member of struct
      sockaddr_xdp was, incorrectly, silently ignored. This patch addresses
      that behavior, and rejects any non-existing flags.
      
      We have examined existing user space code, and to our best knowledge,
      no one is relying on the current incorrect behavior. AF_XDP is still
      in its infancy, so from our perspective, the risk of breakage is very
      low, and addressing this problem now is important.
      
      Fixes: 965a9909 ("xsk: add support for bind for Rx")
      Signed-off-by: default avatarBjörn Töpel <bjorn.topel@intel.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      f54ba391
    • Nikita V. Shirokov's avatar
      bpf, libbpf: fixing leak when kernel does not support btf · 243b4cda
      Nikita V. Shirokov authored
      We could end up in situation when we have object file w/ all btf
      info, but kernel does not support btf yet. In this situation
      currently libbpf just set obj->btf to NULL w/o freeing it first.
      This patch is fixing it by making sure to run btf__free first.
      
      Fixes: d29d87f7 ("btf: separate btf creation and loading")
      Signed-off-by: default avatarNikita V. Shirokov <tehnerd@tehnerd.com>
      Acked-by: default avatarYonghong Song <yhs@fb.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      243b4cda