1. 18 Oct, 2018 21 commits
    • Stefano Brivio's avatar
      ip6_tunnel: Fix encapsulation layout · d4d576f5
      Stefano Brivio authored
      Commit 058214a4 ("ip6_tun: Add infrastructure for doing
      encapsulation") added the ip6_tnl_encap() call in ip6_tnl_xmit(), before
      the call to ipv6_push_frag_opts() to append the IPv6 Tunnel Encapsulation
      Limit option (option 4, RFC 2473, par. 5.1) to the outer IPv6 header.
      
      As long as the option didn't actually end up in generated packets, this
      wasn't an issue. Then commit 89a23c8b ("ip6_tunnel: Fix missing tunnel
      encapsulation limit option") fixed sending of this option, and the
      resulting layout, e.g. for FoU, is:
      
      .-------------------.------------.----------.-------------------.----- - -
      | Outer IPv6 Header | UDP header | Option 4 | Inner IPv6 Header | Payload
      '-------------------'------------'----------'-------------------'----- - -
      
      Needless to say, FoU and GUE (at least) won't work over IPv6. The option
      is appended by default, and I couldn't find a way to disable it with the
      current iproute2.
      
      Turn this into a more reasonable:
      
      .-------------------.----------.------------.-------------------.----- - -
      | Outer IPv6 Header | Option 4 | UDP header | Inner IPv6 Header | Payload
      '-------------------'----------'------------'-------------------'----- - -
      
      With this, and with 84dad559 ("udp6: fix encap return code for
      resubmitting"), FoU and GUE work again over IPv6.
      
      Fixes: 058214a4 ("ip6_tun: Add infrastructure for doing encapsulation")
      Signed-off-by: default avatarStefano Brivio <sbrivio@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d4d576f5
    • Jon Maloy's avatar
      tipc: fix info leak from kernel tipc_event · b06f9d9f
      Jon Maloy authored
      We initialize a struct tipc_event allocated on the kernel stack to
      zero to avert info leak to user space.
      
      Reported-by: syzbot+057458894bc8cada4dee@syzkaller.appspotmail.com
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b06f9d9f
    • Wenwen Wang's avatar
      net: socket: fix a missing-check bug · b6168562
      Wenwen Wang authored
      In ethtool_ioctl(), the ioctl command 'ethcmd' is checked through a switch
      statement to see whether it is necessary to pre-process the ethtool
      structure, because, as mentioned in the comment, the structure
      ethtool_rxnfc is defined with padding. If yes, a user-space buffer 'rxnfc'
      is allocated through compat_alloc_user_space(). One thing to note here is
      that, if 'ethcmd' is ETHTOOL_GRXCLSRLALL, the size of the buffer 'rxnfc' is
      partially determined by 'rule_cnt', which is actually acquired from the
      user-space buffer 'compat_rxnfc', i.e., 'compat_rxnfc->rule_cnt', through
      get_user(). After 'rxnfc' is allocated, the data in the original user-space
      buffer 'compat_rxnfc' is then copied to 'rxnfc' through copy_in_user(),
      including the 'rule_cnt' field. However, after this copy, no check is
      re-enforced on 'rxnfc->rule_cnt'. So it is possible that a malicious user
      race to change the value in the 'compat_rxnfc->rule_cnt' between these two
      copies. Through this way, the attacker can bypass the previous check on
      'rule_cnt' and inject malicious data. This can cause undefined behavior of
      the kernel and introduce potential security risk.
      
      This patch avoids the above issue via copying the value acquired by
      get_user() to 'rxnfc->rule_cn', if 'ethcmd' is ETHTOOL_GRXCLSRLALL.
      Signed-off-by: default avatarWenwen Wang <wang6495@umn.edu>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b6168562
    • Phil Sutter's avatar
      net: sched: Fix for duplicate class dump · 3c53ed8f
      Phil Sutter authored
      When dumping classes by parent, kernel would return classes twice:
      
      | # tc qdisc add dev lo root prio
      | # tc class show dev lo
      | class prio 8001:1 parent 8001:
      | class prio 8001:2 parent 8001:
      | class prio 8001:3 parent 8001:
      | # tc class show dev lo parent 8001:
      | class prio 8001:1 parent 8001:
      | class prio 8001:2 parent 8001:
      | class prio 8001:3 parent 8001:
      | class prio 8001:1 parent 8001:
      | class prio 8001:2 parent 8001:
      | class prio 8001:3 parent 8001:
      
      This comes from qdisc_match_from_root() potentially returning the root
      qdisc itself if its handle matched. Though in that case, root's classes
      were already dumped a few lines above.
      
      Fixes: cb395b20 ("net: sched: optimize class dumps")
      Signed-off-by: default avatarPhil Sutter <phil@nwl.cc>
      Reviewed-by: default avatarJiri Pirko <jiri@mellanox.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3c53ed8f
    • Heiner Kallweit's avatar
      r8169: fix NAPI handling under high load · 6b839b6c
      Heiner Kallweit authored
      rtl_rx() and rtl_tx() are called only if the respective bits are set
      in the interrupt status register. Under high load NAPI may not be
      able to process all data (work_done == budget) and it will schedule
      subsequent calls to the poll callback.
      rtl_ack_events() however resets the bits in the interrupt status
      register, therefore subsequent calls to rtl8169_poll() won't call
      rtl_rx() and rtl_tx() - chip interrupts are still disabled.
      
      Fix this by calling rtl_rx() and rtl_tx() independent of the bits
      set in the interrupt status register. Both functions will detect
      if there's nothing to do for them.
      
      Fixes: da78dbff ("r8169: remove work from irq handler.")
      Signed-off-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6b839b6c
    • David S. Miller's avatar
      Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec · 2ee653f6
      David S. Miller authored
      Steffen Klassert says:
      
      ====================
      pull request (net): ipsec 2018-10-18
      
      1) Free the xfrm interface gro_cells when deleting the
         interface, otherwise we leak it. From Li RongQing.
      
      2) net/core/flow.c does not exist anymore, so remove it
         from the MAINTAINERS file.
      
      3) Fix a slab-out-of-bounds in _decode_session6.
         From Alexei Starovoitov.
      
      4) Fix RCU protection when policies inserted into
         thei bydst lists. From Florian Westphal.
      
      Please pull or let me know if there are problems.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2ee653f6
    • Nikolay Aleksandrov's avatar
      net: ipmr: fix unresolved entry dumps · eddf016b
      Nikolay Aleksandrov authored
      If the skb space ends in an unresolved entry while dumping we'll miss
      some unresolved entries. The reason is due to zeroing the entry counter
      between dumping resolved and unresolved mfc entries. We should just
      keep counting until the whole table is dumped and zero when we move to
      the next as we have a separate table counter.
      Reported-by: default avatarColin Ian King <colin.king@canonical.com>
      Fixes: 8fb472c0 ("ipmr: improve hash scalability")
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      eddf016b
    • Gregory CLEMENT's avatar
      net: mscc: ocelot: Fix comment in ocelot_vlant_wait_for_completion() · 06a36ecb
      Gregory CLEMENT authored
      The ocelot_vlant_wait_for_completion() function is very similar to the
      ocelot_mact_wait_for_completion(). It seemed to have be copied but the
      comment was not updated, so let's fix it.
      Signed-off-by: default avatarGregory CLEMENT <gregory.clement@bootlin.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      06a36ecb
    • Xin Long's avatar
      sctp: fix the data size calculation in sctp_data_size · 5660b9d9
      Xin Long authored
      sctp data size should be calculated by subtracting data chunk header's
      length from chunk_hdr->length, not just data header.
      
      Fixes: 668c9beb ("sctp: implement assign_number for sctp_stream_interleave")
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Acked-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5660b9d9
    • Ake Koomsin's avatar
      virtio_net: avoid using netif_tx_disable() for serializing tx routine · 05c998b7
      Ake Koomsin authored
      Commit 713a98d9 ("virtio-net: serialize tx routine during reset")
      introduces netif_tx_disable() after netif_device_detach() in order to
      avoid use-after-free of tx queues. However, there are two issues.
      
      1) Its operation is redundant with netif_device_detach() in case the
         interface is running.
      2) In case of the interface is not running before suspending and
         resuming, the tx does not get resumed by netif_device_attach().
         This results in losing network connectivity.
      
      It is better to use netif_tx_lock_bh()/netif_tx_unlock_bh() instead for
      serializing tx routine during reset. This also preserves the symmetry
      of netif_device_detach() and netif_device_attach().
      
      Fixes commit 713a98d9 ("virtio-net: serialize tx routine during reset")
      Signed-off-by: default avatarAke Koomsin <ake@igel.co.jp>
      Acked-by: default avatarJason Wang <jasowang@redhat.com>
      Acked-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      05c998b7
    • Paolo Abeni's avatar
      udp6: fix encap return code for resubmitting · 84dad559
      Paolo Abeni authored
      The commit eb63f296 ("udp6: add missing checks on edumux packet
      processing") used the same return code convention of the ipv4 counterpart,
      but ipv6 uses the opposite one: positive values means resubmit.
      
      This change addresses the issue, using positive return value for
      resubmitting. Also update the related comment, which was broken, too.
      
      Fixes: eb63f296 ("udp6: add missing checks on edumux packet processing")
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      84dad559
    • Ido Schimmel's avatar
      mlxsw: core: Fix use-after-free when flashing firmware during init · 9b3bc7db
      Ido Schimmel authored
      When the switch driver (e.g., mlxsw_spectrum) determines it needs to
      flash a new firmware version it resets the ASIC after the flashing
      process. The bus driver (e.g., mlxsw_pci) then registers itself again
      with mlxsw_core which means (among other things) that the device
      registers itself again with the hwmon subsystem again.
      
      Since the device was registered with the hwmon subsystem using
      devm_hwmon_device_register_with_groups(), then the old hwmon device
      (registered before the flashing) was never unregistered and was
      referencing stale data, resulting in a use-after free.
      
      Fix by removing reliance on device managed APIs in mlxsw_hwmon_init().
      
      Fixes: c86d62cc ("mlxsw: spectrum: Reset FW after flash")
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Reported-by: default avatarAlexander Petrovskiy <alexpe@mellanox.com>
      Tested-by: default avatarAlexander Petrovskiy <alexpe@mellanox.com>
      Reviewed-by: default avatarPetr Machata <petrm@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9b3bc7db
    • Xin Long's avatar
      sctp: not free the new asoc when sctp_wait_for_connect returns err · c863850c
      Xin Long authored
      When sctp_wait_for_connect is called to wait for connect ready
      for sp->strm_interleave in sctp_sendmsg_to_asoc, a panic could
      be triggered if cpu is scheduled out and the new asoc is freed
      elsewhere, as it will return err and later the asoc gets freed
      again in sctp_sendmsg.
      
      [  285.840764] list_del corruption, ffff9f0f7b284078->next is LIST_POISON1 (dead000000000100)
      [  285.843590] WARNING: CPU: 1 PID: 8861 at lib/list_debug.c:47 __list_del_entry_valid+0x50/0xa0
      [  285.846193] Kernel panic - not syncing: panic_on_warn set ...
      [  285.846193]
      [  285.848206] CPU: 1 PID: 8861 Comm: sctp_ndata Kdump: loaded Not tainted 4.19.0-rc7.label #584
      [  285.850559] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
      [  285.852164] Call Trace:
      ...
      [  285.872210]  ? __list_del_entry_valid+0x50/0xa0
      [  285.872894]  sctp_association_free+0x42/0x2d0 [sctp]
      [  285.873612]  sctp_sendmsg+0x5a4/0x6b0 [sctp]
      [  285.874236]  sock_sendmsg+0x30/0x40
      [  285.874741]  ___sys_sendmsg+0x27a/0x290
      [  285.875304]  ? __switch_to_asm+0x34/0x70
      [  285.875872]  ? __switch_to_asm+0x40/0x70
      [  285.876438]  ? ptep_set_access_flags+0x2a/0x30
      [  285.877083]  ? do_wp_page+0x151/0x540
      [  285.877614]  __sys_sendmsg+0x58/0xa0
      [  285.878138]  do_syscall_64+0x55/0x180
      [  285.878669]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      This is a similar issue with the one fixed in Commit ca3af4dd
      ("sctp: do not free asoc when it is already dead in sctp_sendmsg").
      But this one can't be fixed by returning -ESRCH for the dead asoc
      in sctp_wait_for_connect, as it will break sctp_connect's return
      value to users.
      
      This patch is to simply set err to -ESRCH before it returns to
      sctp_sendmsg when any err is returned by sctp_wait_for_connect
      for sp->strm_interleave, so that no asoc would be freed due to
      this.
      
      When users see this error, they will know the packet hasn't been
      sent. And it also makes sense to not free asoc because waiting
      connect fails, like the second call for sctp_wait_for_connect in
      sctp_sendmsg_to_asoc.
      
      Fixes: 668c9beb ("sctp: implement assign_number for sctp_stream_interleave")
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Acked-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c863850c
    • Marcelo Ricardo Leitner's avatar
      sctp: fix race on sctp_id2asoc · b336deca
      Marcelo Ricardo Leitner authored
      syzbot reported an use-after-free involving sctp_id2asoc.  Dmitry Vyukov
      helped to root cause it and it is because of reading the asoc after it
      was freed:
      
              CPU 1                       CPU 2
      (working on socket 1)            (working on socket 2)
      	                         sctp_association_destroy
      sctp_id2asoc
         spin lock
           grab the asoc from idr
         spin unlock
                                         spin lock
      				     remove asoc from idr
      				   spin unlock
      				   free(asoc)
         if asoc->base.sk != sk ... [*]
      
      This can only be hit if trying to fetch asocs from different sockets. As
      we have a single IDR for all asocs, in all SCTP sockets, their id is
      unique on the system. An application can try to send stuff on an id
      that matches on another socket, and the if in [*] will protect from such
      usage. But it didn't consider that as that asoc may belong to another
      socket, it may be freed in parallel (read: under another socket lock).
      
      We fix it by moving the checks in [*] into the protected region. This
      fixes it because the asoc cannot be freed while the lock is held.
      
      Reported-by: syzbot+c7dd55d7aec49d48e49a@syzkaller.appspotmail.com
      Acked-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b336deca
    • Heiner Kallweit's avatar
      r8169: re-enable MSI-X on RTL8168g · 9675931e
      Heiner Kallweit authored
      Similar to d49c88d7 ("r8169: Enable MSI-X on RTL8106e") after
      e9d0ba506ea8 ("PCI: Reprogram bridge prefetch registers on resume")
      we can safely assume that this also fixes the root cause of
      the issue worked around by 7c53a722 ("r8169: don't use MSI-X on
      RTL8168g"). So let's revert it.
      
      Fixes: 7c53a722 ("r8169: don't use MSI-X on RTL8168g")
      Signed-off-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9675931e
    • Taehee Yoo's avatar
      net: bpfilter: use get_pid_task instead of pid_task · 84258438
      Taehee Yoo authored
      pid_task() dereferences rcu protected tasks array.
      But there is no rcu_read_lock() in shutdown_umh() routine so that
      rcu_read_lock() is needed.
      get_pid_task() is wrapper function of pid_task. it holds rcu_read_lock()
      then calls pid_task(). if task isn't NULL, it increases reference count
      of task.
      
      test commands:
         %modprobe bpfilter
         %modprobe -rv bpfilter
      
      splat looks like:
      [15102.030932] =============================
      [15102.030957] WARNING: suspicious RCU usage
      [15102.030985] 4.19.0-rc7+ #21 Not tainted
      [15102.031010] -----------------------------
      [15102.031038] kernel/pid.c:330 suspicious rcu_dereference_check() usage!
      [15102.031063]
      	       other info that might help us debug this:
      
      [15102.031332]
      	       rcu_scheduler_active = 2, debug_locks = 1
      [15102.031363] 1 lock held by modprobe/1570:
      [15102.031389]  #0: 00000000580ef2b0 (bpfilter_lock){+.+.}, at: stop_umh+0x13/0x52 [bpfilter]
      [15102.031552]
                     stack backtrace:
      [15102.031583] CPU: 1 PID: 1570 Comm: modprobe Not tainted 4.19.0-rc7+ #21
      [15102.031607] Hardware name: To be filled by O.E.M. To be filled by O.E.M./Aptio CRB, BIOS 5.6.5 07/08/2015
      [15102.031628] Call Trace:
      [15102.031676]  dump_stack+0xc9/0x16b
      [15102.031723]  ? show_regs_print_info+0x5/0x5
      [15102.031801]  ? lockdep_rcu_suspicious+0x117/0x160
      [15102.031855]  pid_task+0x134/0x160
      [15102.031900]  ? find_vpid+0xf0/0xf0
      [15102.032017]  shutdown_umh.constprop.1+0x1e/0x53 [bpfilter]
      [15102.032055]  stop_umh+0x46/0x52 [bpfilter]
      [15102.032092]  __x64_sys_delete_module+0x47e/0x570
      [ ... ]
      
      Fixes: d2ba09c1 ("net: add skeleton of bpfilter kernel module")
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      84258438
    • Gustavo A. R. Silva's avatar
      ptp: fix Spectre v1 vulnerability · efa61c8c
      Gustavo A. R. Silva authored
      pin_index can be indirectly controlled by user-space, hence leading
      to a potential exploitation of the Spectre variant 1 vulnerability.
      
      This issue was detected with the help of Smatch:
      
      drivers/ptp/ptp_chardev.c:253 ptp_ioctl() warn: potential spectre issue
      'ops->pin_config' [r] (local cap)
      
      Fix this by sanitizing pin_index before using it to index
      ops->pin_config, and before passing it as an argument to
      function ptp_set_pinfunc(), in which it is used to index
      info->pin_config.
      
      Notice that given that speculation windows are large, the policy is
      to kill the speculation on the first load and not worry if it can be
      completed with a dependent load/store [1].
      
      [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Acked-by: default avatarRichard Cochran <richardcochran@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      efa61c8c
    • Nathan Chancellor's avatar
      net: qla3xxx: Remove overflowing shift statement · 8c3bf9b6
      Nathan Chancellor authored
      Clang currently warns:
      
      drivers/net/ethernet/qlogic/qla3xxx.c:384:24: warning: signed shift
      result (0xF00000000) requires 37 bits to represent, but 'int' only has
      32 bits [-Wshift-overflow]
                          ((ISP_NVRAM_MASK << 16) | qdev->eeprom_cmd_data));
                            ~~~~~~~~~~~~~~ ^  ~~
      1 warning generated.
      
      The warning is certainly accurate since ISP_NVRAM_MASK is defined as
      (0x000F << 16) which is then shifted by 16, resulting in 64424509440,
      well above UINT_MAX.
      
      Given that this is the only location in this driver where ISP_NVRAM_MASK
      is shifted again, it seems likely that ISP_NVRAM_MASK was originally
      defined without a shift and during the move of the shift to the
      definition, this statement wasn't properly removed (since ISP_NVRAM_MASK
      is used in the statenent right above this). Only the maintainers can
      confirm this since this statment has been here since the driver was
      first added to the kernel.
      
      Link: https://github.com/ClangBuiltLinux/linux/issues/127Signed-off-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8c3bf9b6
    • David S. Miller's avatar
      Merge branch 'geneve-vxlan-mtu' · dc6d0f0b
      David S. Miller authored
      Stefano Brivio says:
      
      ====================
      geneve, vxlan: Don't set exceptions if skb->len < mtu
      
      This series fixes the exception abuse described in 2/2, and 1/2
      is just a preparatory change to make 2/2 less ugly.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      dc6d0f0b
    • Stefano Brivio's avatar
      geneve, vxlan: Don't set exceptions if skb->len < mtu · 6b4f92af
      Stefano Brivio authored
      We shouldn't abuse exceptions: if the destination MTU is already higher
      than what we're transmitting, no exception should be created.
      
      Fixes: 52a589d5 ("geneve: update skb dst pmtu on tx path")
      Fixes: a93bf0ff ("vxlan: update skb dst pmtu on tx path")
      Signed-off-by: default avatarStefano Brivio <sbrivio@redhat.com>
      Reviewed-by: default avatarSabrina Dubroca <sd@queasysnail.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6b4f92af
    • Stefano Brivio's avatar
      geneve, vxlan: Don't check skb_dst() twice · 7463e4f9
      Stefano Brivio authored
      Commit f15ca723 ("net: don't call update_pmtu unconditionally") avoids
      that we try updating PMTU for a non-existent destination, but didn't clean
      up cases where the check was already explicit. Drop those redundant checks.
      Signed-off-by: default avatarStefano Brivio <sbrivio@redhat.com>
      Reviewed-by: default avatarSabrina Dubroca <sd@queasysnail.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7463e4f9
  2. 16 Oct, 2018 19 commits
    • Xin Long's avatar
      sctp: get pr_assoc and pr_stream all status with SCTP_PR_SCTP_ALL instead · 0ac1077e
      Xin Long authored
      According to rfc7496 section 4.3 or 4.4:
      
         sprstat_policy:  This parameter indicates for which PR-SCTP policy
            the user wants the information.  It is an error to use
            SCTP_PR_SCTP_NONE in sprstat_policy.  If SCTP_PR_SCTP_ALL is used,
            the counters provided are aggregated over all supported policies.
      
      We change to dump pr_assoc and pr_stream all status by SCTP_PR_SCTP_ALL
      instead, and return error for SCTP_PR_SCTP_NONE, as it also said "It is
      an error to use SCTP_PR_SCTP_NONE in sprstat_policy. "
      
      Fixes: 826d253d ("sctp: add SCTP_PR_ASSOC_STATUS on sctp sockopt")
      Fixes: d229d48d ("sctp: add SCTP_PR_STREAM_STATUS sockopt for prsctp")
      Reported-by: default avatarYing Xu <yinxu@redhat.com>
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0ac1077e
    • David S. Miller's avatar
      Merge branch 'nfp-fix-pedit-set-action-offloads' · bd8be2cf
      David S. Miller authored
      Jakub Kicinski says:
      
      ====================
      nfp: fix pedit set action offloads
      
      Pieter says:
      
      This set fixes set actions when using multiple pedit actions with
      partial masks and with multiple keys per pedit action. Additionally
      it fixes set ipv6 pedit action offloads when using it in combination
      with other header keys.
      
      The problem would only trigger if one combines multiple pedit actions
      of the same type with partial masks, e.g.:
      
      $ tc filter add dev netdev protocol ip parent ffff: \
          flower indev netdev \
          ip_proto tcp \
          action pedit ex munge \
          ip src set 11.11.11.11 retain 65535 munge \
          ip src set 22.22.22.22 retain 4294901760 pipe \
          csum ip and tcp pipe \
          mirred egress redirect dev netdev
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bd8be2cf
    • Pieter Jansen van Vuuren's avatar
      nfp: flower: use offsets provided by pedit instead of index for ipv6 · 140b6aba
      Pieter Jansen van Vuuren authored
      Previously when populating the set ipv6 address action, we incorrectly
      made use of pedit's key index to determine which 32bit word should be
      set. We now calculate which word has been selected based on the offset
      provided by the pedit action.
      
      Fixes: 354b82bb ("nfp: add set ipv6 source and destination address")
      Signed-off-by: default avatarPieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      140b6aba
    • Pieter Jansen van Vuuren's avatar
      nfp: flower: fix multiple keys per pedit action · d08c9e58
      Pieter Jansen van Vuuren authored
      Previously we only allowed a single header key per pedit action to
      change the header. This used to result in the last header key in the
      pedit action to overwrite previous headers. We now keep track of them
      and allow multiple header keys per pedit action.
      
      Fixes: c0b1bd9a ("nfp: add set ipv4 header action flower offload")
      Fixes: 354b82bb ("nfp: add set ipv6 source and destination address")
      Fixes: f8b7b0a6 ("nfp: add set tcp and udp header action flower offload")
      Signed-off-by: default avatarPieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d08c9e58
    • Pieter Jansen van Vuuren's avatar
      nfp: flower: fix pedit set actions for multiple partial masks · 8913806f
      Pieter Jansen van Vuuren authored
      Previously we did not correctly change headers when using multiple
      pedit actions with partial masks. We now take this into account and
      no longer just commit the last pedit action.
      
      Fixes: c0b1bd9a ("nfp: add set ipv4 header action flower offload")
      Signed-off-by: default avatarPieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8913806f
    • David Howells's avatar
      rxrpc: Fix a missing rxrpc_put_peer() in the error_report handler · 1890fea7
      David Howells authored
      Fix a missing call to rxrpc_put_peer() on the main path through the
      rxrpc_error_report() function.  This manifests itself as a ref leak
      whenever an ICMP packet or other error comes in.
      
      In commit f3344303, the hand-off of the ref to a work item was removed
      and was not replaced with a put.
      
      Fixes: f3344303 ("rxrpc: Fix error distribution")
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1890fea7
    • Xin Long's avatar
      sctp: use the pmtu from the icmp packet to update transport pathmtu · d805397c
      Xin Long authored
      Other than asoc pmtu sync from all transports, sctp_assoc_sync_pmtu
      is also processing transport pmtu_pending by icmp packets. But it's
      meaningless to use sctp_dst_mtu(t->dst) as new pmtu for a transport.
      
      The right pmtu value should come from the icmp packet, and it would
      be saved into transport->mtu_info in this patch and used later when
      the pmtu sync happens in sctp_sendmsg_to_asoc or sctp_packet_config.
      
      Besides, without this patch, as pmtu can only be updated correctly
      when receiving a icmp packet and no place is holding sock lock, it
      will take long time if the sock is busy with sending packets.
      
      Note that it doesn't process transport->mtu_info in .release_cb(),
      as there is no enough information for pmtu update, like for which
      asoc or transport. It is not worth traversing all asocs to check
      pmtu_pending. So unlike tcp, sctp does this in tx path, for which
      mtu_info needs to be atomic_t.
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Acked-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d805397c
    • Fugang Duan's avatar
      net: fec: don't dump RX FIFO register when not available · ec20a63a
      Fugang Duan authored
      Commit db65f35f ("net: fec: add support of ethtool get_regs") introduce
      ethool "--register-dump" interface to dump all FEC registers.
      
      But not all silicon implementations of the Freescale FEC hardware module
      have the FRBR (FIFO Receive Bound Register) and FRSR (FIFO Receive Start
      Register) register, so we should not be trying to dump them on those that
      don't.
      
      To fix it we create a quirk flag, FEC_QUIRK_HAS_RFREG, and check it before
      dump those RX FIFO registers.
      Signed-off-by: default avatarFugang Duan <fugang.duan@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ec20a63a
    • Colin Ian King's avatar
      qed: fix spelling mistake "Ireelevant" -> "Irrelevant" · fbe1222c
      Colin Ian King authored
      Trivial fix to spelling mistake in DP_INFO message
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fbe1222c
    • Eric Dumazet's avatar
      ipv6: mcast: fix a use-after-free in inet6_mc_check · dc012f36
      Eric Dumazet authored
      syzbot found a use-after-free in inet6_mc_check [1]
      
      The problem here is that inet6_mc_check() uses rcu
      and read_lock(&iml->sflock)
      
      So the fact that ip6_mc_leave_src() is called under RTNL
      and the socket lock does not help us, we need to acquire
      iml->sflock in write mode.
      
      In the future, we should convert all this stuff to RCU.
      
      [1]
      BUG: KASAN: use-after-free in ipv6_addr_equal include/net/ipv6.h:521 [inline]
      BUG: KASAN: use-after-free in inet6_mc_check+0xae7/0xb40 net/ipv6/mcast.c:649
      Read of size 8 at addr ffff8801ce7f2510 by task syz-executor0/22432
      
      CPU: 1 PID: 22432 Comm: syz-executor0 Not tainted 4.19.0-rc7+ #280
      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+0x1c4/0x2b4 lib/dump_stack.c:113
       print_address_description.cold.8+0x9/0x1ff mm/kasan/report.c:256
       kasan_report_error mm/kasan/report.c:354 [inline]
       kasan_report.cold.9+0x242/0x309 mm/kasan/report.c:412
       __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
       ipv6_addr_equal include/net/ipv6.h:521 [inline]
       inet6_mc_check+0xae7/0xb40 net/ipv6/mcast.c:649
       __raw_v6_lookup+0x320/0x3f0 net/ipv6/raw.c:98
       ipv6_raw_deliver net/ipv6/raw.c:183 [inline]
       raw6_local_deliver+0x3d3/0xcb0 net/ipv6/raw.c:240
       ip6_input_finish+0x467/0x1aa0 net/ipv6/ip6_input.c:345
       NF_HOOK include/linux/netfilter.h:289 [inline]
       ip6_input+0xe9/0x600 net/ipv6/ip6_input.c:426
       ip6_mc_input+0x48a/0xd20 net/ipv6/ip6_input.c:503
       dst_input include/net/dst.h:450 [inline]
       ip6_rcv_finish+0x17a/0x330 net/ipv6/ip6_input.c:76
       NF_HOOK include/linux/netfilter.h:289 [inline]
       ipv6_rcv+0x120/0x640 net/ipv6/ip6_input.c:271
       __netif_receive_skb_one_core+0x14d/0x200 net/core/dev.c:4913
       __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:5023
       netif_receive_skb_internal+0x12c/0x620 net/core/dev.c:5126
       napi_frags_finish net/core/dev.c:5664 [inline]
       napi_gro_frags+0x75a/0xc90 net/core/dev.c:5737
       tun_get_user+0x3189/0x4250 drivers/net/tun.c:1923
       tun_chr_write_iter+0xb9/0x154 drivers/net/tun.c:1968
       call_write_iter include/linux/fs.h:1808 [inline]
       do_iter_readv_writev+0x8b0/0xa80 fs/read_write.c:680
       do_iter_write+0x185/0x5f0 fs/read_write.c:959
       vfs_writev+0x1f1/0x360 fs/read_write.c:1004
       do_writev+0x11a/0x310 fs/read_write.c:1039
       __do_sys_writev fs/read_write.c:1112 [inline]
       __se_sys_writev fs/read_write.c:1109 [inline]
       __x64_sys_writev+0x75/0xb0 fs/read_write.c:1109
       do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x457421
      Code: 75 14 b8 14 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 34 b5 fb ff c3 48 83 ec 08 e8 1a 2d 00 00 48 89 04 24 b8 14 00 00 00 0f 05 <48> 8b 3c 24 48 89 c2 e8 63 2d 00 00 48 89 d0 48 83 c4 08 48 3d 01
      RSP: 002b:00007f2d30ecaba0 EFLAGS: 00000293 ORIG_RAX: 0000000000000014
      RAX: ffffffffffffffda RBX: 000000000000003e RCX: 0000000000457421
      RDX: 0000000000000001 RSI: 00007f2d30ecabf0 RDI: 00000000000000f0
      RBP: 0000000020000500 R08: 00000000000000f0 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000293 R12: 00007f2d30ecb6d4
      R13: 00000000004c4890 R14: 00000000004d7b90 R15: 00000000ffffffff
      
      Allocated by task 22437:
       save_stack+0x43/0xd0 mm/kasan/kasan.c:448
       set_track mm/kasan/kasan.c:460 [inline]
       kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:553
       __do_kmalloc mm/slab.c:3718 [inline]
       __kmalloc+0x14e/0x760 mm/slab.c:3727
       kmalloc include/linux/slab.h:518 [inline]
       sock_kmalloc+0x15a/0x1f0 net/core/sock.c:1983
       ip6_mc_source+0x14dd/0x1960 net/ipv6/mcast.c:427
       do_ipv6_setsockopt.isra.9+0x3afb/0x45d0 net/ipv6/ipv6_sockglue.c:743
       ipv6_setsockopt+0xbd/0x170 net/ipv6/ipv6_sockglue.c:933
       rawv6_setsockopt+0x59/0x140 net/ipv6/raw.c:1069
       sock_common_setsockopt+0x9a/0xe0 net/core/sock.c:3038
       __sys_setsockopt+0x1ba/0x3c0 net/socket.c:1902
       __do_sys_setsockopt net/socket.c:1913 [inline]
       __se_sys_setsockopt net/socket.c:1910 [inline]
       __x64_sys_setsockopt+0xbe/0x150 net/socket.c:1910
       do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Freed by task 22430:
       save_stack+0x43/0xd0 mm/kasan/kasan.c:448
       set_track mm/kasan/kasan.c:460 [inline]
       __kasan_slab_free+0x102/0x150 mm/kasan/kasan.c:521
       kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
       __cache_free mm/slab.c:3498 [inline]
       kfree+0xcf/0x230 mm/slab.c:3813
       __sock_kfree_s net/core/sock.c:2004 [inline]
       sock_kfree_s+0x29/0x60 net/core/sock.c:2010
       ip6_mc_leave_src+0x11a/0x1d0 net/ipv6/mcast.c:2448
       __ipv6_sock_mc_close+0x20b/0x4e0 net/ipv6/mcast.c:310
       ipv6_sock_mc_close+0x158/0x1d0 net/ipv6/mcast.c:328
       inet6_release+0x40/0x70 net/ipv6/af_inet6.c:452
       __sock_release+0xd7/0x250 net/socket.c:579
       sock_close+0x19/0x20 net/socket.c:1141
       __fput+0x385/0xa30 fs/file_table.c:278
       ____fput+0x15/0x20 fs/file_table.c:309
       task_work_run+0x1e8/0x2a0 kernel/task_work.c:113
       tracehook_notify_resume include/linux/tracehook.h:193 [inline]
       exit_to_usermode_loop+0x318/0x380 arch/x86/entry/common.c:166
       prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
       syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
       do_syscall_64+0x6be/0x820 arch/x86/entry/common.c:293
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      The buggy address belongs to the object at ffff8801ce7f2500
       which belongs to the cache kmalloc-192 of size 192
      The buggy address is located 16 bytes inside of
       192-byte region [ffff8801ce7f2500, ffff8801ce7f25c0)
      The buggy address belongs to the page:
      page:ffffea000739fc80 count:1 mapcount:0 mapping:ffff8801da800040 index:0x0
      flags: 0x2fffc0000000100(slab)
      raw: 02fffc0000000100 ffffea0006f6e548 ffffea000737b948 ffff8801da800040
      raw: 0000000000000000 ffff8801ce7f2000 0000000100000010 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff8801ce7f2400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff8801ce7f2480: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
      >ffff8801ce7f2500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                               ^
       ffff8801ce7f2580: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
       ffff8801ce7f2600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      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>
      dc012f36
    • Tung Nguyen's avatar
      tipc: fix unsafe rcu locking when accessing publication list · d3092b2e
      Tung Nguyen authored
      The binding table's 'cluster_scope' list is rcu protected to handle
      races between threads changing the list and those traversing the list at
      the same moment. We have now found that the function named_distribute()
      uses the regular list_for_each() macro to traverse the said list.
      Likewise, the function tipc_named_withdraw() is removing items from the
      same list using the regular list_del() call. When these two functions
      execute in parallel we see occasional crashes.
      
      This commit fixes this by adding the missing _rcu() suffixes.
      Signed-off-by: default avatarTung Nguyen <tung.q.nguyen@dektech.com.au>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d3092b2e
    • David Howells's avatar
      rxrpc: Fix incorrect conditional on IPV6 · 7ec8dc96
      David Howells authored
      The udpv6_encap_enable() function is part of the ipv6 code, and if that is
      configured as a loadable module and rxrpc is built in then a build failure
      will occur because the conditional check is wrong:
      
        net/rxrpc/local_object.o: In function `rxrpc_lookup_local':
        local_object.c:(.text+0x2688): undefined reference to `udpv6_encap_enable'
      
      Use the correct config symbol (CONFIG_AF_RXRPC_IPV6) in the conditional
      check rather than CONFIG_IPV6 as that will do the right thing.
      
      Fixes: 5271953c ("rxrpc: Use the UDP encap_rcv hook")
      Reported-by: kbuild-all@01.org
      Reported-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Reviewed-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7ec8dc96
    • Sabrina Dubroca's avatar
      ipv6: rate-limit probes for neighbourless routes · f547fac6
      Sabrina Dubroca authored
      When commit 27097255 ("[IPV6]: ROUTE: Add Router Reachability
      Probing (RFC4191).") introduced router probing, the rt6_probe() function
      required that a neighbour entry existed. This neighbour entry is used to
      record the timestamp of the last probe via the ->updated field.
      
      Later, commit 2152caea ("ipv6: Do not depend on rt->n in rt6_probe().")
      removed the requirement for a neighbour entry. Neighbourless routes skip
      the interval check and are not rate-limited.
      
      This patch adds rate-limiting for neighbourless routes, by recording the
      timestamp of the last probe in the fib6_info itself.
      
      Fixes: 2152caea ("ipv6: Do not depend on rt->n in rt6_probe().")
      Signed-off-by: default avatarSabrina Dubroca <sd@queasysnail.net>
      Reviewed-by: default avatarStefano Brivio <sbrivio@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f547fac6
    • Florian Fainelli's avatar
      net: bcmgenet: Poll internal PHY for GENETv5 · 64bd9c81
      Florian Fainelli authored
      On GENETv5, there is a hardware issue which prevents the GENET hardware
      from generating a link UP interrupt when the link is operating at
      10Mbits/sec. Since we do not have any way to configure the link
      detection logic, fallback to polling in that case.
      
      Fixes: 42138085 ("net: bcmgenet: add support for the GENETv5 hardware")
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      64bd9c81
    • YueHaibing's avatar
      rxrpc: use correct kvec num when sending BUSY response packet · d6672a5a
      YueHaibing authored
      Fixes gcc '-Wunused-but-set-variable' warning:
      
      net/rxrpc/output.c: In function 'rxrpc_reject_packets':
      net/rxrpc/output.c:527:11: warning:
       variable 'ioc' set but not used [-Wunused-but-set-variable]
      
      'ioc' is the correct kvec num when sending a BUSY (or an ABORT) response
      packet.
      
      Fixes: ece64fec ("rxrpc: Emit BUSY packets when supposed to rather than ABORTs")
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d6672a5a
    • David Howells's avatar
      rxrpc: Fix an uninitialised variable · d7b4c24f
      David Howells authored
      Fix an uninitialised variable introduced by the last patch.  This can cause
      a crash when a new call comes in to a local service, such as when an AFS
      fileserver calls back to the local cache manager.
      
      Fixes: c1e15b49 ("rxrpc: Fix the packet reception routine")
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d7b4c24f
    • Jon Maloy's avatar
      tipc: initialize broadcast link stale counter correctly · 4af00f4c
      Jon Maloy authored
      In the commit referred to below we added link tolerance as an additional
      criteria for declaring broadcast transmission "stale" and resetting the
      unicast links to the affected node.
      
      Unfortunately, this 'improvement' introduced two bugs, which each and
      one alone cause only limited problems, but combined lead to seemingly
      stochastic unicast link resets, depending on the amount of broadcast
      traffic transmitted.
      
      The first issue, a missing initialization of the 'tolerance' field of
      the receiver broadcast link, was recently fixed by commit 047491ea
      ("tipc: set link tolerance correctly in broadcast link").
      
      Ths second issue, where we omit to reset the 'stale_cnt' field of
      the same link after a 'stale' period is over, leads to this counter
      accumulating over time, and in the absence of the 'tolerance' criteria
      leads to the above described symptoms. This commit adds the missing
      initialization.
      
      Fixes: a4dc70d4 ("tipc: extend link reset criteria for stale packet retransmission")
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Acked-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4af00f4c
    • Cong Wang's avatar
      llc: set SOCK_RCU_FREE in llc_sap_add_socket() · 5a8e7aea
      Cong Wang authored
      WHen an llc sock is added into the sk_laddr_hash of an llc_sap,
      it is not marked with SOCK_RCU_FREE.
      
      This causes that the sock could be freed while it is still being
      read by __llc_lookup_established() with RCU read lock. sock is
      refcounted, but with RCU read lock, nothing prevents the readers
      getting a zero refcnt.
      
      Fix it by setting SOCK_RCU_FREE in llc_sap_add_socket().
      
      Reported-by: syzbot+11e05f04c15e03be5254@syzkaller.appspotmail.com
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5a8e7aea
    • David S. Miller's avatar
      Merge tag 'mlx5-fixes-2018-10-10' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux · d0f068e5
      David S. Miller authored
      Saeed Mahameed says:
      
      ====================
      Mellanox, mlx5 fixes 2018-10-10
      
      This pull request includes some fixes to mlx5 driver,
      Please pull and let me know if there's any problem.
      
      For -stable v4.11:
      ('net/mlx5: Take only bit 24-26 of wqe.pftype_wq for page fault type')
      For -stable v4.17:
      ('net/mlx5: Fix memory leak when setting fpga ipsec caps')
      For -stable v4.18:
      ('net/mlx5: WQ, fixes for fragmented WQ buffers API')
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d0f068e5