1. 30 3月, 2021 2 次提交
    • L
      net:tipc: Fix a double free in tipc_sk_mcast_rcv · 6bf24dc0
      Lv Yunlong 提交于
      In the if(skb_peek(arrvq) == skb) branch, it calls __skb_dequeue(arrvq) to get
      the skb by skb = skb_peek(arrvq). Then __skb_dequeue() unlinks the skb from arrvq
      and returns the skb which equals to skb_peek(arrvq). After __skb_dequeue(arrvq)
      finished, the skb is freed by kfree_skb(__skb_dequeue(arrvq)) in the first time.
      
      Unfortunately, the same skb is freed in the second time by kfree_skb(skb) after
      the branch completed.
      
      My patch removes kfree_skb() in the if(skb_peek(arrvq) == skb) branch, because
      this skb will be freed by kfree_skb(skb) finally.
      
      Fixes: cb1b7280 ("tipc: eliminate race condition at multicast reception")
      Signed-off-by: NLv Yunlong <lyl2019@mail.ustc.edu.cn>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6bf24dc0
    • M
      net: dsa: Fix type was not set for devlink port · fb6ec87f
      Maxim Kochetkov 提交于
      If PHY is not available on DSA port (described at devicetree but absent or
      failed to detect) then kernel prints warning after 3700 secs:
      
      [ 3707.948771] ------------[ cut here ]------------
      [ 3707.948784] Type was not set for devlink port.
      [ 3707.948894] WARNING: CPU: 1 PID: 17 at net/core/devlink.c:8097 0xc083f9d8
      
      We should unregister the devlink port as a user port and
      re-register it as an unused port before executing "continue" in case of
      dsa_port_setup error.
      
      Fixes: 86f8b1c0 ("net: dsa: Do not make user port errors fatal")
      Signed-off-by: NMaxim Kochetkov <fido_max@inbox.ru>
      Reviewed-by: NVladimir Oltean <olteanv@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fb6ec87f
  2. 29 3月, 2021 2 次提交
  3. 26 3月, 2021 5 次提交
  4. 24 3月, 2021 2 次提交
    • V
      net: bridge: don't notify switchdev for local FDB addresses · 6ab4c311
      Vladimir Oltean 提交于
      As explained in this discussion:
      https://lore.kernel.org/netdev/20210117193009.io3nungdwuzmo5f7@skbuf/
      
      the switchdev notifiers for FDB entries managed to have a zero-day bug.
      The bridge would not say that this entry is local:
      
      ip link add br0 type bridge
      ip link set swp0 master br0
      bridge fdb add dev swp0 00:01:02:03:04:05 master local
      
      and the switchdev driver would be more than happy to offload it as a
      normal static FDB entry. This is despite the fact that 'local' and
      non-'local' entries have completely opposite directions: a local entry
      is locally terminated and not forwarded, whereas a static entry is
      forwarded and not locally terminated. So, for example, DSA would install
      this entry on swp0 instead of installing it on the CPU port as it should.
      
      There is an even sadder part, which is that the 'local' flag is implicit
      if 'static' is not specified, meaning that this command produces the
      same result of adding a 'local' entry:
      
      bridge fdb add dev swp0 00:01:02:03:04:05 master
      
      I've updated the man pages for 'bridge', and after reading it now, it
      should be pretty clear to any user that the commands above were broken
      and should have never resulted in the 00:01:02:03:04:05 address being
      forwarded (this behavior is coherent with non-switchdev interfaces):
      https://patchwork.kernel.org/project/netdevbpf/cover/20210211104502.2081443-1-olteanv@gmail.com/
      If you're a user reading this and this is what you want, just use:
      
      bridge fdb add dev swp0 00:01:02:03:04:05 master static
      
      Because switchdev should have given drivers the means from day one to
      classify FDB entries as local/non-local, but didn't, it means that all
      drivers are currently broken. So we can just as well omit the switchdev
      notifications for local FDB entries, which is exactly what this patch
      does to close the bug in stable trees. For further development work
      where drivers might want to trap the local FDB entries to the host, we
      can add a 'bool is_local' to br_switchdev_fdb_call_notifiers(), and
      selectively make drivers act upon that bit, while all the others ignore
      those entries if the 'is_local' bit is set.
      
      Fixes: 6b26b51b ("net: bridge: Add support for notifying devices about FDB add/del")
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6ab4c311
    • M
      net/sched: act_ct: clear post_ct if doing ct_clear · 8ca1b090
      Marcelo Ricardo Leitner 提交于
      Invalid detection works with two distinct moments: act_ct tries to find
      a conntrack entry and set post_ct true, indicating that that was
      attempted. Then, when flow dissector tries to dissect CT info and no
      entry is there, it knows that it was tried and no entry was found, and
      synthesizes/sets
                        key->ct_state = TCA_FLOWER_KEY_CT_FLAGS_TRACKED |
                                        TCA_FLOWER_KEY_CT_FLAGS_INVALID;
      mimicing what OVS does.
      
      OVS has this a bit more streamlined, as it recomputes the key after
      trying to find a conntrack entry for it.
      
      Issue here is, when we have 'tc action ct clear', it didn't clear
      post_ct, causing a subsequent match on 'ct_state -trk' to fail, due to
      the above. The fix, thus, is to clear it.
      
      Reproducer rules:
      tc filter add dev enp130s0f0np0_0 ingress prio 1 chain 0 \
      	protocol ip flower ip_proto tcp ct_state -trk \
      	action ct zone 1 pipe \
      	action goto chain 2
      tc filter add dev enp130s0f0np0_0 ingress prio 1 chain 2 \
      	protocol ip flower \
      	action ct clear pipe \
      	action goto chain 4
      tc filter add dev enp130s0f0np0_0 ingress prio 1 chain 4 \
      	protocol ip flower ct_state -trk \
      	action mirred egress redirect dev enp130s0f1np1_0
      
      With the fix, the 3rd rule matches, like it does with OVS kernel
      datapath.
      
      Fixes: 7baf2429 ("net/sched: cls_flower add CT_FLAGS_INVALID flag support")
      Signed-off-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Reviewed-by: Nwenxu <wenxu@ucloud.cn>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8ca1b090
  5. 23 3月, 2021 2 次提交
  6. 21 3月, 2021 1 次提交
  7. 20 3月, 2021 2 次提交
  8. 19 3月, 2021 2 次提交
    • J
      net: check all name nodes in __dev_alloc_name · 6c015a22
      Jiri Bohac 提交于
      __dev_alloc_name(), when supplied with a name containing '%d',
      will search for the first available device number to generate a
      unique device name.
      
      Since commit ff927412 ("net:
      introduce name_node struct to be used in hashlist") network
      devices may have alternate names.  __dev_alloc_name() does take
      these alternate names into account, possibly generating a name
      that is already taken and failing with -ENFILE as a result.
      
      This demonstrates the bug:
      
          # rmmod dummy 2>/dev/null
          # ip link property add dev lo altname dummy0
          # modprobe dummy numdummies=1
          modprobe: ERROR: could not insert 'dummy': Too many open files in system
      
      Instead of creating a device named dummy1, modprobe fails.
      
      Fix this by checking all the names in the d->name_node list, not just d->name.
      Signed-off-by: NJiri Bohac <jbohac@suse.cz>
      Fixes: ff927412 ("net: introduce name_node struct to be used in hashlist")
      Reviewed-by: NJiri Pirko <jiri@nvidia.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6c015a22
    • J
      ipv6: weaken the v4mapped source check · dcc32f4f
      Jakub Kicinski 提交于
      This reverts commit 6af1799a.
      
      Commit 6af1799a ("ipv6: drop incoming packets having a v4mapped
      source address") introduced an input check against v4mapped addresses.
      Use of such addresses on the wire is indeed questionable and not
      allowed on public Internet. As the commit pointed out
      
        https://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful-02
      
      lists potential issues.
      
      Unfortunately there are applications which use v4mapped addresses,
      and breaking them is a clear regression. For example v4mapped
      addresses (or any semi-valid addresses, really) may be used
      for uni-direction event streams or packet export.
      
      Since the issue which sparked the addition of the check was with
      TCP and request_socks in particular push the check down to TCPv6
      and DCCP. This restores the ability to receive UDPv6 packets with
      v4mapped address as the source.
      
      Keep using the IPSTATS_MIB_INHDRERRORS statistic to minimize the
      user-visible changes.
      
      Fixes: 6af1799a ("ipv6: drop incoming packets having a v4mapped source address")
      Reported-by: NSunyi Shao <sunyishao@fb.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      Acked-by: NMat Martineau <mathew.j.martineau@linux.intel.com>
      Reviewed-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      dcc32f4f
  9. 18 3月, 2021 8 次提交
  10. 17 3月, 2021 9 次提交
  11. 16 3月, 2021 5 次提交
    • M
      can: isotp: TX-path: ensure that CAN frame flags are initialized · d4eb538e
      Marc Kleine-Budde 提交于
      The previous patch ensures that the TX flags (struct
      can_isotp_ll_options::tx_flags) are 0 for classic CAN frames or a user
      configured value for CAN-FD frames.
      
      This patch sets the CAN frames flags unconditionally to the ISO-TP TX
      flags, so that they are initialized to a proper value. Otherwise when
      running "candump -x" on a classical CAN ISO-TP stream shows wrongly
      set "B" and "E" flags.
      
      | $ candump any,0:0,#FFFFFFFF -extA
      | [...]
      | can0  TX B E  713   [8]  2B 0A 0B 0C 0D 0E 0F 00
      | can0  TX B E  713   [8]  2C 01 02 03 04 05 06 07
      | can0  TX B E  713   [8]  2D 08 09 0A 0B 0C 0D 0E
      | can0  TX B E  713   [8]  2E 0F 00 01 02 03 04 05
      
      Fixes: e057dd3f ("can: add ISO 15765-2:2016 transport protocol")
      Link: https://lore.kernel.org/r/20210218215434.1708249-2-mkl@pengutronix.de
      Cc: Oliver Hartkopp <socketcan@hartkopp.net>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      d4eb538e
    • M
      can: isotp: isotp_setsockopt(): only allow to set low level TX flags for CAN-FD · e4912459
      Marc Kleine-Budde 提交于
      CAN-FD frames have struct canfd_frame::flags, while classic CAN frames
      don't.
      
      This patch refuses to set TX flags (struct
      can_isotp_ll_options::tx_flags) on non CAN-FD isotp sockets.
      
      Fixes: e057dd3f ("can: add ISO 15765-2:2016 transport protocol")
      Link: https://lore.kernel.org/r/20210218215434.1708249-2-mkl@pengutronix.de
      Cc: Oliver Hartkopp <socketcan@hartkopp.net>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      e4912459
    • M
      can: dev: Move device back to init netns on owning netns delete · 3a5ca857
      Martin Willi 提交于
      When a non-initial netns is destroyed, the usual policy is to delete
      all virtual network interfaces contained, but move physical interfaces
      back to the initial netns. This keeps the physical interface visible
      on the system.
      
      CAN devices are somewhat special, as they define rtnl_link_ops even
      if they are physical devices. If a CAN interface is moved into a
      non-initial netns, destroying that netns lets the interface vanish
      instead of moving it back to the initial netns. default_device_exit()
      skips CAN interfaces due to having rtnl_link_ops set. Reproducer:
      
        ip netns add foo
        ip link set can0 netns foo
        ip netns delete foo
      
      WARNING: CPU: 1 PID: 84 at net/core/dev.c:11030 ops_exit_list+0x38/0x60
      CPU: 1 PID: 84 Comm: kworker/u4:2 Not tainted 5.10.19 #1
      Workqueue: netns cleanup_net
      [<c010e700>] (unwind_backtrace) from [<c010a1d8>] (show_stack+0x10/0x14)
      [<c010a1d8>] (show_stack) from [<c086dc10>] (dump_stack+0x94/0xa8)
      [<c086dc10>] (dump_stack) from [<c086b938>] (__warn+0xb8/0x114)
      [<c086b938>] (__warn) from [<c086ba10>] (warn_slowpath_fmt+0x7c/0xac)
      [<c086ba10>] (warn_slowpath_fmt) from [<c0629f20>] (ops_exit_list+0x38/0x60)
      [<c0629f20>] (ops_exit_list) from [<c062a5c4>] (cleanup_net+0x230/0x380)
      [<c062a5c4>] (cleanup_net) from [<c0142c20>] (process_one_work+0x1d8/0x438)
      [<c0142c20>] (process_one_work) from [<c0142ee4>] (worker_thread+0x64/0x5a8)
      [<c0142ee4>] (worker_thread) from [<c0148a98>] (kthread+0x148/0x14c)
      [<c0148a98>] (kthread) from [<c0100148>] (ret_from_fork+0x14/0x2c)
      
      To properly restore physical CAN devices to the initial netns on owning
      netns exit, introduce a flag on rtnl_link_ops that can be set by drivers.
      For CAN devices setting this flag, default_device_exit() considers them
      non-virtual, applying the usual namespace move.
      
      The issue was introduced in the commit mentioned below, as at that time
      CAN devices did not have a dellink() operation.
      
      Fixes: e008b5fc ("net: Simplfy default_device_exit and improve batching.")
      Link: https://lore.kernel.org/r/20210302122423.872326-1-martin@strongswan.orgSigned-off-by: NMartin Willi <martin@strongswan.org>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      3a5ca857
    • D
      mptcp: fix ADD_ADDR HMAC in case port is specified · 13832ae2
      Davide Caratti 提交于
      Currently, Linux computes the HMAC contained in ADD_ADDR sub-option using
      the Address Id and the IP Address, and hardcodes a destination port equal
      to zero. This is not ok for ADD_ADDR with port: ensure to account for the
      endpoint port when computing the HMAC, in compliance with RFC8684 §3.4.1.
      
      Fixes: 22fb85ff ("mptcp: add port support for ADD_ADDR suboption writing")
      Reviewed-by: NMat Martineau <mathew.j.martineau@linux.intel.com>
      Acked-by: NGeliang Tang <geliangtang@gmail.com>
      Signed-off-by: NDavide Caratti <dcaratti@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      13832ae2
    • A
      tcp: relookup sock for RST+ACK packets handled by obsolete req sock · 7233da86
      Alexander Ovechkin 提交于
      Currently tcp_check_req can be called with obsolete req socket for which big
      socket have been already created (because of CPU race or early demux
      assigning req socket to multiple packets in gro batch).
      
      Commit e0f9759f ("tcp: try to keep packet if SYN_RCV race
      is lost") added retry in case when tcp_check_req is called for PSH|ACK packet.
      But if client sends RST+ACK immediatly after connection being
      established (it is performing healthcheck, for example) retry does not
      occur. In that case tcp_check_req tries to close req socket,
      leaving big socket active.
      
      Fixes: e0f9759f ("tcp: try to keep packet if SYN_RCV race is lost")
      Signed-off-by: NAlexander Ovechkin <ovov@yandex-team.ru>
      Reported-by: NOleg Senin <olegsenin@yandex-team.ru>
      Reviewed-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7233da86