1. 14 Feb, 2019 11 commits
  2. 13 Feb, 2019 5 commits
    • Saeed Mahameed's avatar
      net/mlx5e: XDP, fix redirect resources availability check · 407e17b1
      Saeed Mahameed authored
      Currently mlx5 driver creates xdp redirect hw queues unconditionally on
      netdevice open, This is great until someone starts redirecting XDP traffic
      via ndo_xdp_xmit on mlx5 device and changes the device configuration at
      the same time, this might cause crashes, since the other device's napi
      is not aware of the mlx5 state change (resources un-availability).
      
      To fix this we must synchronize with other devices napi's on the system.
      Added a new flag under mlx5e_priv to determine XDP TX resources are
      available, set/clear it up when necessary and use synchronize_rcu()
      when the flag is turned off, so other napi's are in-sync with it, before
      we actually cleanup the hw resources.
      
      The flag is tested prior to committing to transmit on mlx5e_xdp_xmit, and
      it is sufficient to determine if it safe to transmit or not. The other
      two internal flags (MLX5E_STATE_OPENED and MLX5E_SQ_STATE_ENABLED) become
      unnecessary. Thus, they are removed from data path.
      
      Fixes: 58b99ee3 ("net/mlx5e: Add support for XDP_REDIRECT in device-out side")
      Reported-by: default avatarToke Høiland-Jørgensen <toke@redhat.com>
      Reviewed-by: default avatarTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      407e17b1
    • Tariq Toukan's avatar
      net/mlx5: Fix a compilation warning in events.c · 5400261e
      Tariq Toukan authored
      Eliminate the following compilation warning:
      
      drivers/net/ethernet/mellanox/mlx5/core/events.c: warning: 'error_str'
      may be used uninitialized in this function [-Wuninitialized]:  => 238:3
      
      Fixes: c2fb3db2 ("net/mlx5: Rework handling of port module events")
      Signed-off-by: default avatarTariq Toukan <tariqt@mellanox.com>
      Reviewed-by: default avatarMikhael Goikhman <migo@mellanox.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      5400261e
    • Huy Nguyen's avatar
      net/mlx5: No command allowed when command interface is not ready · 4cab346b
      Huy Nguyen authored
      When EEH is injected and PCI bus stalls, mlx5's pci error detect
      function is called to deactivate the command interface and tear down
      the device. The issue is that there can be a thread that already
      passed MLX5_DEVICE_STATE_INTERNAL_ERROR check, it will send the command
      and stuck in the wait_func.
      
      Solution:
      Add function mlx5_cmd_flush to disable command interface and clear all
      the pending commands. When device state is set to
      MLX5_DEVICE_STATE_INTERNAL_ERROR, call mlx5_cmd_flush to ensure all
      pending threads waiting for firmware commands completion are terminated.
      
      Fixes: c1d4d2e9 ("net/mlx5: Avoid calling sleeping function by the health poll thread")
      Signed-off-by: default avatarHuy Nguyen <huyn@mellanox.com>
      Reviewed-by: default avatarDaniel Jurgens <danielj@mellanox.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      4cab346b
    • Maria Pasechnik's avatar
      net/mlx5e: Fix NULL pointer derefernce in set channels error flow · fb35c534
      Maria Pasechnik authored
      New channels are applied to the priv channels only after they
      are successfully opened. Then, the indirection table should be built
      according to the new number of channels.
      Currently, such build is preformed independently of whether the
      channels opening is successful, and is not reverted on failure.
      
      The bug is caused due to removal of rss params from channels struct
      and moving it to priv struct. That change cause to independency between
      channels and rss params.
      This causes a crash on a later point, when accessing rqn of a non
      existing channel.
      
      This patch fixes it by moving the indirection table build right before
      switching the priv channels to new channels struct, after the new set of
      channels was successfully opened.
      
      Fixes: bbeb53b8 ("net/mlx5e: Move RSS params to a dedicated struct")
      Signed-off-by: default avatarMaria Pasechnik <mariap@mellanox.com>
      Reviewed-by: default avatarTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      fb35c534
    • Pablo Neira Ayuso's avatar
      netfilter: nft_compat: use-after-free when deleting targets · 753c111f
      Pablo Neira Ayuso authored
      Fetch pointer to module before target object is released.
      
      Fixes: 29e38801 ("netfilter: nf_tables: fix use-after-free when deleting compat expressions")
      Fixes: 0ca743a5 ("netfilter: nf_tables: add compatibility layer for x_tables")
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      753c111f
  3. 12 Feb, 2019 21 commits
    • Cong Wang's avatar
      team: avoid complex list operations in team_nl_cmd_options_set() · 2fdeee25
      Cong Wang authored
      The current opt_inst_list operations inside team_nl_cmd_options_set()
      is too complex to track:
      
          LIST_HEAD(opt_inst_list);
          nla_for_each_nested(...) {
              list_for_each_entry(opt_inst, &team->option_inst_list, list) {
                  if (__team_option_inst_tmp_find(&opt_inst_list, opt_inst))
                      continue;
                  list_add(&opt_inst->tmp_list, &opt_inst_list);
              }
          }
          team_nl_send_event_options_get(team, &opt_inst_list);
      
      as while we retrieve 'opt_inst' from team->option_inst_list, it could
      be added to the local 'opt_inst_list' for multiple times. The
      __team_option_inst_tmp_find() doesn't work, as the setter
      team_mode_option_set() still calls team->ops.exit() which uses
      ->tmp_list too in __team_options_change_check().
      
      Simplify the list operations by moving the 'opt_inst_list' and
      team_nl_send_event_options_get() into the nla_for_each_nested() loop so
      that it can be guranteed that we won't insert a same list entry for
      multiple times. Therefore, __team_option_inst_tmp_find() can be removed
      too.
      
      Fixes: 4fb0534f ("team: avoid adding twice the same option to the event list")
      Fixes: 2fcdb2c9 ("team: allow to send multiple set events in one message")
      Reported-by: syzbot+4d4af685432dc0e56c91@syzkaller.appspotmail.com
      Reported-by: syzbot+68ee510075cf64260cc4@syzkaller.appspotmail.com
      Cc: Jiri Pirko <jiri@resnulli.us>
      Cc: Paolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Reviewed-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2fdeee25
    • David S. Miller's avatar
      Merge branch 'net_sched-some-fixes-for-cls_tcindex' · a090d794
      David S. Miller authored
      Cong Wang says:
      
      ====================
      net_sched: some fixes for cls_tcindex
      
      This patchset contains 3 bug fixes for tcindex filter. Please check
      each patch for details.
      
      v2: fix a compile error in patch 2
          drop netns refcnt in patch 1
      ====================
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      a090d794
    • Cong Wang's avatar
      net_sched: fix two more memory leaks in cls_tcindex · 1db817e7
      Cong Wang authored
      struct tcindex_filter_result contains two parts:
      struct tcf_exts and struct tcf_result.
      
      For the local variable 'cr', its exts part is never used but
      initialized without being released properly on success path. So
      just completely remove the exts part to fix this leak.
      
      For the local variable 'new_filter_result', it is never properly
      released if not used by 'r' on success path.
      
      Cc: Jamal Hadi Salim <jhs@mojatatu.com>
      Cc: Jiri Pirko <jiri@resnulli.us>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1db817e7
    • Cong Wang's avatar
      net_sched: fix a memory leak in cls_tcindex · 033b228e
      Cong Wang authored
      When tcindex_destroy() destroys all the filter results in
      the perfect hash table, it invokes the walker to delete
      each of them. However, results with class==0 are skipped
      in either tcindex_walk() or tcindex_delete(), which causes
      a memory leak reported by kmemleak.
      
      This patch fixes it by skipping the walker and directly
      deleting these filter results so we don't miss any filter
      result.
      
      As a result of this change, we have to initialize exts->net
      properly in tcindex_alloc_perfect_hash(). For net-next, we
      need to consider whether we should initialize ->net in
      tcf_exts_init() instead, before that just directly test
      CONFIG_NET_CLS_ACT=y.
      
      Cc: Jamal Hadi Salim <jhs@mojatatu.com>
      Cc: Jiri Pirko <jiri@resnulli.us>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      033b228e
    • Cong Wang's avatar
      net_sched: fix a race condition in tcindex_destroy() · 8015d93e
      Cong Wang authored
      tcindex_destroy() invokes tcindex_destroy_element() via
      a walker to delete each filter result in its perfect hash
      table, and tcindex_destroy_element() calls tcindex_delete()
      which schedules tcf RCU works to do the final deletion work.
      Unfortunately this races with the RCU callback
      __tcindex_destroy(), which could lead to use-after-free as
      reported by Adrian.
      
      Fix this by migrating this RCU callback to tcf RCU work too,
      as that workqueue is ordered, we will not have use-after-free.
      
      Note, we don't need to hold netns refcnt because we don't call
      tcf_exts_destroy() here.
      
      Fixes: 27ce4f05 ("net_sched: use tcf_queue_work() in tcindex filter")
      Reported-by: default avatarAdrian <bugs@abtelecom.ro>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Cc: Jamal Hadi Salim <jhs@mojatatu.com>
      Cc: Jiri Pirko <jiri@resnulli.us>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8015d93e
    • David S. Miller's avatar
      Merge branch 'ena-races' · 6a7dd172
      David S. Miller authored
      Arthur Kiyanovski says:
      
      ====================
      net: ena: race condition bug fix and version update
      
      This patchset includes a fix to a race condition that can cause
      kernel panic, as well as a driver version update because of this
      fix.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6a7dd172
    • Arthur Kiyanovski's avatar
      net: ena: update driver version from 2.0.2 to 2.0.3 · d9b8656d
      Arthur Kiyanovski authored
      Update driver version due to bug fix.
      Signed-off-by: default avatarArthur Kiyanovski <akiyano@amazon.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d9b8656d
    • Arthur Kiyanovski's avatar
      net: ena: fix race between link up and device initalization · e1f1bd9b
      Arthur Kiyanovski authored
      Fix race condition between ena_update_on_link_change() and
      ena_restore_device().
      
      This race can occur if link notification arrives while the driver
      is performing a reset sequence. In this case link can be set up,
      enabling the device, before it is fully restored. If packets are
      sent at this time, the driver might access uninitialized data
      structures, causing kernel crash.
      
      Move the clearing of ENA_FLAG_ONGOING_RESET and netif_carrier_on()
      after ena_up() to ensure the device is ready when link is set up.
      
      Fixes: d18e4f68 ("net: ena: fix race condition between device reset and link up setup")
      Signed-off-by: default avatarArthur Kiyanovski <akiyano@amazon.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e1f1bd9b
    • Kal Conley's avatar
      net/packet: fix 4gb buffer limit due to overflow check · fc62814d
      Kal Conley authored
      When calculating rb->frames_per_block * req->tp_block_nr the result
      can overflow. Check it for overflow without limiting the total buffer
      size to UINT_MAX.
      
      This change fixes support for packet ring buffers >= UINT_MAX.
      
      Fixes: 8f8d28e4 ("net/packet: fix overflow in check for tp_frame_nr")
      Signed-off-by: default avatarKal Conley <kal.conley@dectris.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fc62814d
    • Konstantin Khlebnikov's avatar
      inet_diag: fix reporting cgroup classid and fallback to priority · 1ec17dbd
      Konstantin Khlebnikov authored
      Field idiag_ext in struct inet_diag_req_v2 used as bitmap of requested
      extensions has only 8 bits. Thus extensions starting from DCTCPINFO
      cannot be requested directly. Some of them included into response
      unconditionally or hook into some of lower 8 bits.
      
      Extension INET_DIAG_CLASS_ID has not way to request from the beginning.
      
      This patch bundle it with INET_DIAG_TCLASS (ipv6 tos), fixes space
      reservation, and documents behavior for other extensions.
      
      Also this patch adds fallback to reporting socket priority. This filed
      is more widely used for traffic classification because ipv4 sockets
      automatically maps TOS to priority and default qdisc pfifo_fast knows
      about that. But priority could be changed via setsockopt SO_PRIORITY so
      INET_DIAG_TOS isn't enough for predicting class.
      
      Also cgroup2 obsoletes net_cls classid (it always zero), but we cannot
      reuse this field for reporting cgroup2 id because it is 64-bit (ino+gen).
      
      So, after this patch INET_DIAG_CLASS_ID will report socket priority
      for most common setup when net_cls isn't set and/or cgroup2 in use.
      
      Fixes: 0888e372 ("net: inet: diag: expose sockets cgroup classid")
      Signed-off-by: default avatarKonstantin Khlebnikov <khlebnikov@yandex-team.ru>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1ec17dbd
    • Eric Dumazet's avatar
      batman-adv: fix uninit-value in batadv_interface_tx() · 4ffcbfac
      Eric Dumazet authored
      KMSAN reported batadv_interface_tx() was possibly using a
      garbage value [1]
      
      batadv_get_vid() does have a pskb_may_pull() call
      but batadv_interface_tx() does not actually make sure
      this did not fail.
      
      [1]
      BUG: KMSAN: uninit-value in batadv_interface_tx+0x908/0x1e40 net/batman-adv/soft-interface.c:231
      CPU: 0 PID: 10006 Comm: syz-executor469 Not tainted 4.20.0-rc7+ #5
      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+0x173/0x1d0 lib/dump_stack.c:113
       kmsan_report+0x12e/0x2a0 mm/kmsan/kmsan.c:613
       __msan_warning+0x82/0xf0 mm/kmsan/kmsan_instr.c:313
       batadv_interface_tx+0x908/0x1e40 net/batman-adv/soft-interface.c:231
       __netdev_start_xmit include/linux/netdevice.h:4356 [inline]
       netdev_start_xmit include/linux/netdevice.h:4365 [inline]
       xmit_one net/core/dev.c:3257 [inline]
       dev_hard_start_xmit+0x607/0xc40 net/core/dev.c:3273
       __dev_queue_xmit+0x2e42/0x3bc0 net/core/dev.c:3843
       dev_queue_xmit+0x4b/0x60 net/core/dev.c:3876
       packet_snd net/packet/af_packet.c:2928 [inline]
       packet_sendmsg+0x8306/0x8f30 net/packet/af_packet.c:2953
       sock_sendmsg_nosec net/socket.c:621 [inline]
       sock_sendmsg net/socket.c:631 [inline]
       __sys_sendto+0x8c4/0xac0 net/socket.c:1788
       __do_sys_sendto net/socket.c:1800 [inline]
       __se_sys_sendto+0x107/0x130 net/socket.c:1796
       __x64_sys_sendto+0x6e/0x90 net/socket.c:1796
       do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
       entry_SYSCALL_64_after_hwframe+0x63/0xe7
      RIP: 0033:0x441889
      Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 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 bb 10 fc ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007ffdda6fd468 EFLAGS: 00000216 ORIG_RAX: 000000000000002c
      RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 0000000000441889
      RDX: 000000000000000e RSI: 00000000200000c0 RDI: 0000000000000003
      RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000216 R12: 00007ffdda6fd4c0
      R13: 00007ffdda6fd4b0 R14: 0000000000000000 R15: 0000000000000000
      
      Uninit was created at:
       kmsan_save_stack_with_flags mm/kmsan/kmsan.c:204 [inline]
       kmsan_internal_poison_shadow+0x92/0x150 mm/kmsan/kmsan.c:158
       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:446 [inline]
       slab_alloc_node mm/slub.c:2759 [inline]
       __kmalloc_node_track_caller+0xe18/0x1030 mm/slub.c:4383
       __kmalloc_reserve net/core/skbuff.c:137 [inline]
       __alloc_skb+0x309/0xa20 net/core/skbuff.c:205
       alloc_skb include/linux/skbuff.h:998 [inline]
       alloc_skb_with_frags+0x1c7/0xac0 net/core/skbuff.c:5220
       sock_alloc_send_pskb+0xafd/0x10e0 net/core/sock.c:2083
       packet_alloc_skb net/packet/af_packet.c:2781 [inline]
       packet_snd net/packet/af_packet.c:2872 [inline]
       packet_sendmsg+0x661a/0x8f30 net/packet/af_packet.c:2953
       sock_sendmsg_nosec net/socket.c:621 [inline]
       sock_sendmsg net/socket.c:631 [inline]
       __sys_sendto+0x8c4/0xac0 net/socket.c:1788
       __do_sys_sendto net/socket.c:1800 [inline]
       __se_sys_sendto+0x107/0x130 net/socket.c:1796
       __x64_sys_sendto+0x6e/0x90 net/socket.c:1796
       do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
       entry_SYSCALL_64_after_hwframe+0x63/0xe7
      
      Fixes: c6c8fea2 ("net: Add batman-adv meshing protocol")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Cc:	Marek Lindner <mareklindner@neomailbox.ch>
      Cc:	Simon Wunderlich <sw@simonwunderlich.de>
      Cc:	Antonio Quartulli <a@unstable.cc>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4ffcbfac
    • Li RongQing's avatar
      ipv6: propagate genlmsg_reply return code · d1f20798
      Li RongQing authored
      genlmsg_reply can fail, so propagate its return code
      
      Fixes: 915d7e5e ("ipv6: sr: add code base for control plane support of SR-IPv6")
      Signed-off-by: default avatarLi RongQing <lirongqing@baidu.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d1f20798
    • Saeed Mahameed's avatar
      net/mlx4_en: Force CHECKSUM_NONE for short ethernet frames · 29dded89
      Saeed Mahameed authored
      When an ethernet frame is padded to meet the minimum ethernet frame
      size, the padding octets are not covered by the hardware checksum.
      Fortunately the padding octets are usually zero's, which don't affect
      checksum. However, it is not guaranteed. For example, switches might
      choose to make other use of these octets.
      This repeatedly causes kernel hardware checksum fault.
      
      Prior to the cited commit below, skb checksum was forced to be
      CHECKSUM_NONE when padding is detected. After it, we need to keep
      skb->csum updated. However, fixing up CHECKSUM_COMPLETE requires to
      verify and parse IP headers, it does not worth the effort as the packets
      are so small that CHECKSUM_COMPLETE has no significant advantage.
      
      Future work: when reporting checksum complete is not an option for
      IP non-TCP/UDP packets, we can actually fallback to report checksum
      unnecessary, by looking at cqe IPOK bit.
      
      Fixes: 88078d98 ("net: pskb_trim_rcsum() and CHECKSUM_COMPLETE are friends")
      Cc: Eric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      Signed-off-by: default avatarTariq Toukan <tariqt@mellanox.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      29dded89
    • Russell King's avatar
      net: phylink: avoid resolving link state too early · 87454b6e
      Russell King authored
      During testing on Armada 388 platforms, it was found with a certain
      module configuration that it was possible to trigger a kernel oops
      during the module load process, caused by the phylink resolver being
      triggered for a currently disabled interface.
      
      This problem was introduced by changing the way the SFP registration
      works, which now can result in the sfp link down notification being
      called during phylink_create().
      
      Fixes: b5bfc21a ("net: sfp: do not probe SFP module before we're attached")
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      87454b6e
    • Matteo Croce's avatar
      geneve: change NET_UDP_TUNNEL dependency to select · a7603ac1
      Matteo Croce authored
      Due to the depends on NET_UDP_TUNNEL, at the moment it is impossible to
      compile GENEVE if no other protocol depending on NET_UDP_TUNNEL is
      selected.
      
      Fix this changing the depends to a select, and drop NET_IP_TUNNEL from the
      select list, as it already depends on NET_UDP_TUNNEL.
      Signed-off-by: default avatarMatteo Croce <mcroce@redhat.com>
      Reviewed-and-tested-by: default avatarAndrea Claudi <aclaudi@redhat.com>
      Tested-by: default avatarDavide Caratti <dcaratti@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a7603ac1
    • Bert Kenward's avatar
      sfc: initialise found bitmap in efx_ef10_mtd_probe · c6528542
      Bert Kenward authored
      The bitmap of found partitions in efx_ef10_mtd_probe was not
      initialised, causing partitions to be suppressed based off whatever
      value was in the bitmap at the start.
      
      Fixes: 33664635 ("sfc: suppress duplicate nvmem partition types in efx_ef10_mtd_probe")
      Signed-off-by: default avatarBert Kenward <bkenward@solarflare.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c6528542
    • David S. Miller's avatar
      Merge tag 'mac80211-for-davem-2019-02-12' of... · 1ea06107
      David S. Miller authored
      Merge tag 'mac80211-for-davem-2019-02-12' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
      
      Johannes Berg says:
      
      ====================
      Just a few fixes:
       * aggregation session teardown with internal TXQs was
         continuing to send some frames marked as aggregation,
         fix from Ilan
       * IBSS join was missed during firmware restart, should
         such a thing happen
       * speculative execution based on the return value of
         cfg80211_classify8021d() - which is controlled by the
         sender of the packet - could be problematic in some
         code using it, prevent it
       * a few peer measurement fixes
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1ea06107
    • Andrea Claudi's avatar
      ipvs: fix dependency on nf_defrag_ipv6 · 098e13f5
      Andrea Claudi authored
      ipvs relies on nf_defrag_ipv6 module to manage IPv6 fragmentation,
      but lacks proper Kconfig dependencies and does not explicitly
      request defrag features.
      
      As a result, if netfilter hooks are not loaded, when IPv6 fragmented
      packet are handled by ipvs only the first fragment makes through.
      
      Fix it properly declaring the dependency on Kconfig and registering
      netfilter hooks on ip_vs_add_service() and ip_vs_new_dest().
      Reported-by: default avatarLi Shuang <shuali@redhat.com>
      Signed-off-by: default avatarAndrea Claudi <aclaudi@redhat.com>
      Acked-by: default avatarJulian Anastasov <ja@ssi.bg>
      Acked-by: default avatarSimon Horman <horms@verge.net.au>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      098e13f5
    • Tuong Lien's avatar
      tipc: fix link session and re-establish issues · 91986ee1
      Tuong Lien authored
      When a link endpoint is re-created (e.g. after a node reboot or
      interface reset), the link session number is varied by random, the peer
      endpoint will be synced with this new session number before the link is
      re-established.
      
      However, there is a shortcoming in this mechanism that can lead to the
      link never re-established or faced with a failure then. It happens when
      the peer endpoint is ready in ESTABLISHING state, the 'peer_session' as
      well as the 'in_session' flag have been set, but suddenly this link
      endpoint leaves. When it comes back with a random session number, there
      are two situations possible:
      
      1/ If the random session number is larger than (or equal to) the
      previous one, the peer endpoint will be updated with this new session
      upon receipt of a RESET_MSG from this endpoint, and the link can be re-
      established as normal. Otherwise, all the RESET_MSGs from this endpoint
      will be rejected by the peer. In turn, when this link endpoint receives
      one ACTIVATE_MSG from the peer, it will move to ESTABLISHED and start
      to send STATE_MSGs, but again these messages will be dropped by the
      peer due to wrong session.
      The peer link endpoint can still become ESTABLISHED after receiving a
      traffic message from this endpoint (e.g. a BCAST_PROTOCOL or
      NAME_DISTRIBUTOR), but since all the STATE_MSGs are invalid, the link
      will be forced down sooner or later!
      
      Even in case the random session number is larger than the previous one,
      it can be that the ACTIVATE_MSG from the peer arrives first, and this
      link endpoint moves quickly to ESTABLISHED without sending out any
      RESET_MSG yet. Consequently, the peer link will not be updated with the
      new session number, and the same link failure scenario as above will
      happen.
      
      2/ Another situation can be that, the peer link endpoint was reset due
      to any reasons in the meantime, its link state was set to RESET from
      ESTABLISHING but still in session, i.e. the 'in_session' flag is not
      reset...
      Now, if the random session number from this endpoint is less than the
      previous one, all the RESET_MSGs from this endpoint will be rejected by
      the peer. In the other direction, when this link endpoint receives a
      RESET_MSG from the peer, it moves to ESTABLISHING and starts to send
      ACTIVATE_MSGs, but all these messages will be rejected by the peer too.
      As a result, the link cannot be re-established but gets stuck with this
      link endpoint in state ESTABLISHING and the peer in RESET!
      
      Solution:
      
      ===========
      
      This link endpoint should not go directly to ESTABLISHED when getting
      ACTIVATE_MSG from the peer which may belong to the old session if the
      link was re-created. To ensure the session to be correct before the
      link is re-established, the peer endpoint in ESTABLISHING state will
      send back the last session number in ACTIVATE_MSG for a verification at
      this endpoint. Then, if needed, a new and more appropriate session
      number will be regenerated to force a re-synch first.
      
      In addition, when a link in ESTABLISHING state is reset, its state will
      move to RESET according to the link FSM, along with resetting the
      'in_session' flag (and the other data) as a normal link reset, it will
      also be deleted if requested.
      
      The solution is backward compatible.
      Acked-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Acked-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarTuong Lien <tuong.t.lien@dektech.com.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      91986ee1
    • Zhiqiang Liu's avatar
      net: fix IPv6 prefix route residue · e75913c9
      Zhiqiang Liu authored
      Follow those steps:
       # ip addr add 2001:123::1/32 dev eth0
       # ip addr add 2001:123:456::2/64 dev eth0
       # ip addr del 2001:123::1/32 dev eth0
       # ip addr del 2001:123:456::2/64 dev eth0
      and then prefix route of 2001:123::1/32 will still exist.
      
      This is because ipv6_prefix_equal in check_cleanup_prefix_route
      func does not check whether two IPv6 addresses have the same
      prefix length. If the prefix of one address starts with another
      shorter address prefix, even though their prefix lengths are
      different, the return value of ipv6_prefix_equal is true.
      
      Here I add a check of whether two addresses have the same prefix
      to decide whether their prefixes are equal.
      
      Fixes: 5b84efec ("ipv6 addrconf: don't cleanup prefix route for IFA_F_NOPREFIXROUTE")
      Signed-off-by: default avatarZhiqiang Liu <liuzhiqiang26@huawei.com>
      Reported-by: default avatarWenhao Zhang <zhangwenhao8@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e75913c9
    • Hoang Le's avatar
      tipc: fix skb may be leaky in tipc_link_input · 7384b538
      Hoang Le authored
      When we free skb at tipc_data_input, we return a 'false' boolean.
      Then, skb passed to subcalling tipc_link_input in tipc_link_rcv,
      
      <snip>
      1303 int tipc_link_rcv:
      ...
      1354    if (!tipc_data_input(l, skb, l->inputq))
      1355        rc |= tipc_link_input(l, skb, l->inputq);
      </snip>
      
      Fix it by simple changing to a 'true' boolean when skb is being free-ed.
      Then, tipc_link_rcv will bypassed to subcalling tipc_link_input as above
      condition.
      Acked-by: default avatarYing Xue <ying.xue@windriver.com>
      Acked-by: default avatarJon Maloy <maloy@donjonn.com>
      Signed-off-by: default avatarHoang Le <hoang.h.le@dektech.com.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7384b538
  4. 11 Feb, 2019 3 commits
    • Francesco Ruggeri's avatar
      netfilter: compat: initialize all fields in xt_init · 8d29d16d
      Francesco Ruggeri authored
      If a non zero value happens to be in xt[NFPROTO_BRIDGE].cur at init
      time, the following panic can be caused by running
      
      % ebtables -t broute -F BROUTING
      
      from a 32-bit user level on a 64-bit kernel. This patch replaces
      kmalloc_array with kcalloc when allocating xt.
      
      [  474.680846] BUG: unable to handle kernel paging request at 0000000009600920
      [  474.687869] PGD 2037006067 P4D 2037006067 PUD 2038938067 PMD 0
      [  474.693838] Oops: 0000 [#1] SMP
      [  474.697055] CPU: 9 PID: 4662 Comm: ebtables Kdump: loaded Not tainted 4.19.17-11302235.AroraKernelnext.fc18.x86_64 #1
      [  474.707721] Hardware name: Supermicro X9DRT/X9DRT, BIOS 3.0 06/28/2013
      [  474.714313] RIP: 0010:xt_compat_calc_jump+0x2f/0x63 [x_tables]
      [  474.720201] Code: 40 0f b6 ff 55 31 c0 48 6b ff 70 48 03 3d dc 45 00 00 48 89 e5 8b 4f 6c 4c 8b 47 60 ff c9 39 c8 7f 2f 8d 14 08 d1 fa 48 63 fa <41> 39 34 f8 4c 8d 0c fd 00 00 00 00 73 05 8d 42 01 eb e1 76 05 8d
      [  474.739023] RSP: 0018:ffffc9000943fc58 EFLAGS: 00010207
      [  474.744296] RAX: 0000000000000000 RBX: ffffc90006465000 RCX: 0000000002580249
      [  474.751485] RDX: 00000000012c0124 RSI: fffffffff7be17e9 RDI: 00000000012c0124
      [  474.758670] RBP: ffffc9000943fc58 R08: 0000000000000000 R09: ffffffff8117cf8f
      [  474.765855] R10: ffffc90006477000 R11: 0000000000000000 R12: 0000000000000001
      [  474.773048] R13: 0000000000000000 R14: ffffc9000943fcb8 R15: ffffc9000943fcb8
      [  474.780234] FS:  0000000000000000(0000) GS:ffff88a03f840000(0063) knlGS:00000000f7ac7700
      [  474.788612] CS:  0010 DS: 002b ES: 002b CR0: 0000000080050033
      [  474.794632] CR2: 0000000009600920 CR3: 0000002037422006 CR4: 00000000000606e0
      [  474.802052] Call Trace:
      [  474.804789]  compat_do_replace+0x1fb/0x2a3 [ebtables]
      [  474.810105]  compat_do_ebt_set_ctl+0x69/0xe6 [ebtables]
      [  474.815605]  ? try_module_get+0x37/0x42
      [  474.819716]  compat_nf_setsockopt+0x4f/0x6d
      [  474.824172]  compat_ip_setsockopt+0x7e/0x8c
      [  474.828641]  compat_raw_setsockopt+0x16/0x3a
      [  474.833220]  compat_sock_common_setsockopt+0x1d/0x24
      [  474.838458]  __compat_sys_setsockopt+0x17e/0x1b1
      [  474.843343]  ? __check_object_size+0x76/0x19a
      [  474.847960]  __ia32_compat_sys_socketcall+0x1cb/0x25b
      [  474.853276]  do_fast_syscall_32+0xaf/0xf6
      [  474.857548]  entry_SYSENTER_compat+0x6b/0x7a
      Signed-off-by: default avatarFrancesco Ruggeri <fruggeri@arista.com>
      Acked-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      8d29d16d
    • Eric Dumazet's avatar
      net/x25: do not hold the cpu too long in x25_new_lci() · cf657d22
      Eric Dumazet authored
      Due to quadratic behavior of x25_new_lci(), syzbot was able
      to trigger an rcu stall.
      
      Fix this by not blocking BH for the whole duration of
      the function, and inserting a reschedule point when possible.
      
      If we care enough, using a bitmap could get rid of the quadratic
      behavior.
      
      syzbot report :
      
      rcu: INFO: rcu_preempt self-detected stall on CPU
      rcu:    0-...!: (10500 ticks this GP) idle=4fa/1/0x4000000000000002 softirq=283376/283376 fqs=0
      rcu:     (t=10501 jiffies g=383105 q=136)
      rcu: rcu_preempt kthread starved for 10502 jiffies! g383105 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=0
      rcu: RCU grace-period kthread stack dump:
      rcu_preempt     I28928    10      2 0x80000000
      Call Trace:
       context_switch kernel/sched/core.c:2844 [inline]
       __schedule+0x817/0x1cc0 kernel/sched/core.c:3485
       schedule+0x92/0x180 kernel/sched/core.c:3529
       schedule_timeout+0x4db/0xfd0 kernel/time/timer.c:1803
       rcu_gp_fqs_loop kernel/rcu/tree.c:1948 [inline]
       rcu_gp_kthread+0x956/0x17a0 kernel/rcu/tree.c:2105
       kthread+0x357/0x430 kernel/kthread.c:246
       ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
      NMI backtrace for cpu 0
      CPU: 0 PID: 8759 Comm: syz-executor2 Not tainted 5.0.0-rc4+ #51
      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+0x172/0x1f0 lib/dump_stack.c:113
       nmi_cpu_backtrace.cold+0x63/0xa4 lib/nmi_backtrace.c:101
       nmi_trigger_cpumask_backtrace+0x1be/0x236 lib/nmi_backtrace.c:62
       arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38
       trigger_single_cpu_backtrace include/linux/nmi.h:164 [inline]
       rcu_dump_cpu_stacks+0x183/0x1cf kernel/rcu/tree.c:1211
       print_cpu_stall kernel/rcu/tree.c:1348 [inline]
       check_cpu_stall kernel/rcu/tree.c:1422 [inline]
       rcu_pending kernel/rcu/tree.c:3018 [inline]
       rcu_check_callbacks.cold+0x500/0xa4a kernel/rcu/tree.c:2521
       update_process_times+0x32/0x80 kernel/time/timer.c:1635
       tick_sched_handle+0xa2/0x190 kernel/time/tick-sched.c:161
       tick_sched_timer+0x47/0x130 kernel/time/tick-sched.c:1271
       __run_hrtimer kernel/time/hrtimer.c:1389 [inline]
       __hrtimer_run_queues+0x33e/0xde0 kernel/time/hrtimer.c:1451
       hrtimer_interrupt+0x314/0x770 kernel/time/hrtimer.c:1509
       local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1035 [inline]
       smp_apic_timer_interrupt+0x120/0x570 arch/x86/kernel/apic/apic.c:1060
       apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:807
       </IRQ>
      RIP: 0010:__read_once_size include/linux/compiler.h:193 [inline]
      RIP: 0010:queued_write_lock_slowpath+0x13e/0x290 kernel/locking/qrwlock.c:86
      Code: 00 00 fc ff df 4c 8d 2c 01 41 83 c7 03 41 0f b6 45 00 41 38 c7 7c 08 84 c0 0f 85 0c 01 00 00 8b 03 3d 00 01 00 00 74 1a f3 90 <41> 0f b6 55 00 41 38 d7 7c eb 84 d2 74 e7 48 89 df e8 6c 0f 4f 00
      RSP: 0018:ffff88805f117bd8 EFLAGS: 00000206 ORIG_RAX: ffffffffffffff13
      RAX: 0000000000000300 RBX: ffffffff89413ba0 RCX: 1ffffffff1282774
      RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffff89413ba0
      RBP: ffff88805f117c70 R08: 1ffffffff1282774 R09: fffffbfff1282775
      R10: fffffbfff1282774 R11: ffffffff89413ba3 R12: 00000000000000ff
      R13: fffffbfff1282774 R14: 1ffff1100be22f7d R15: 0000000000000003
       queued_write_lock include/asm-generic/qrwlock.h:104 [inline]
       do_raw_write_lock+0x1d6/0x290 kernel/locking/spinlock_debug.c:203
       __raw_write_lock_bh include/linux/rwlock_api_smp.h:204 [inline]
       _raw_write_lock_bh+0x3b/0x50 kernel/locking/spinlock.c:312
       x25_insert_socket+0x21/0xe0 net/x25/af_x25.c:267
       x25_bind+0x273/0x340 net/x25/af_x25.c:705
       __sys_bind+0x23f/0x290 net/socket.c:1505
       __do_sys_bind net/socket.c:1516 [inline]
       __se_sys_bind net/socket.c:1514 [inline]
       __x64_sys_bind+0x73/0xb0 net/socket.c:1514
       do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x457e39
      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:00007fafccd0dc78 EFLAGS: 00000246 ORIG_RAX: 0000000000000031
      RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000457e39
      RDX: 0000000000000012 RSI: 0000000020000240 RDI: 0000000000000004
      RBP: 000000000073bf00 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00007fafccd0e6d4
      R13: 00000000004bdf8b R14: 00000000004ce4b8 R15: 00000000ffffffff
      Sending NMI from CPU 0 to CPUs 1:
      NMI backtrace for cpu 1
      CPU: 1 PID: 8752 Comm: syz-executor4 Not tainted 5.0.0-rc4+ #51
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      RIP: 0010:__x25_find_socket+0x78/0x120 net/x25/af_x25.c:328
      Code: 89 f8 48 c1 e8 03 80 3c 18 00 0f 85 a6 00 00 00 4d 8b 64 24 68 4d 85 e4 74 7f e8 03 97 3d fb 49 83 ec 68 74 74 e8 f8 96 3d fb <49> 8d bc 24 88 04 00 00 48 89 f8 48 c1 e8 03 0f b6 04 18 84 c0 74
      RSP: 0018:ffff8880639efc58 EFLAGS: 00000246
      RAX: 0000000000040000 RBX: dffffc0000000000 RCX: ffffc9000e677000
      RDX: 0000000000040000 RSI: ffffffff863244b8 RDI: ffff88806a764628
      RBP: ffff8880639efc80 R08: ffff8880a80d05c0 R09: fffffbfff1282775
      R10: fffffbfff1282774 R11: ffffffff89413ba3 R12: ffff88806a7645c0
      R13: 0000000000000001 R14: ffff88809f29ac00 R15: 0000000000000000
      FS:  00007fe8d0c58700(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000001b32823000 CR3: 00000000672eb000 CR4: 00000000001406e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       x25_new_lci net/x25/af_x25.c:357 [inline]
       x25_connect+0x374/0xdf0 net/x25/af_x25.c:786
       __sys_connect+0x266/0x330 net/socket.c:1686
       __do_sys_connect net/socket.c:1697 [inline]
       __se_sys_connect net/socket.c:1694 [inline]
       __x64_sys_connect+0x73/0xb0 net/socket.c:1694
       do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x457e39
      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:00007fe8d0c57c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002a
      RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000457e39
      RDX: 0000000000000012 RSI: 0000000020000200 RDI: 0000000000000004
      RBP: 000000000073bf00 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe8d0c586d4
      R13: 00000000004be378 R14: 00000000004ceb00 R15: 00000000ffffffff
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Cc: Andrew Hendry <andrew.hendry@gmail.com>
      Cc: linux-x25@vger.kernel.org
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cf657d22
    • Eric Dumazet's avatar
      vxlan: test dev->flags & IFF_UP before calling netif_rx() · 4179cb5a
      Eric Dumazet authored
      netif_rx() 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.
      
      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.
      
      Note this patch also fixes a small issue that came
      with commit ce6502a8 ("vxlan: fix a use after free
      in vxlan_encap_bypass"), since the dev->stats.rx_dropped
      change was done on the wrong device.
      
      Fixes: d342894c ("vxlan: virtual extensible lan")
      Fixes: ce6502a8 ("vxlan: fix a use after free in vxlan_encap_bypass")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Petr Machata <petrm@mellanox.com>
      Cc: Ido Schimmel <idosch@mellanox.com>
      Cc: Roopa Prabhu <roopa@cumulusnetworks.com>
      Cc: Stefano Brivio <sbrivio@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4179cb5a