1. 07 9月, 2022 3 次提交
  2. 29 8月, 2022 1 次提交
    • J
      genetlink: start to validate reserved header bytes · 9c5d03d3
      Jakub Kicinski 提交于
      We had historically not checked that genlmsghdr.reserved
      is 0 on input which prevents us from using those precious
      bytes in the future.
      
      One use case would be to extend the cmd field, which is
      currently just 8 bits wide and 256 is not a lot of commands
      for some core families.
      
      To make sure that new families do the right thing by default
      put the onus of opting out of validation on existing families.
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      Acked-by: Paul Moore <paul@paul-moore.com> (NetLabel)
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9c5d03d3
  3. 20 8月, 2022 1 次提交
  4. 10 8月, 2022 1 次提交
    • C
      macsec: Fix traffic counters/statistics · 91ec9bd5
      Clayton Yager 提交于
      OutOctetsProtected, OutOctetsEncrypted, InOctetsValidated, and
      InOctetsDecrypted were incrementing by the total number of octets in frames
      instead of by the number of octets of User Data in frames.
      
      The Controlled Port statistics ifOutOctets and ifInOctets were incrementing
      by the total number of octets instead of the number of octets of the MSDUs
      plus octets of the destination and source MAC addresses.
      
      The Controlled Port statistics ifInDiscards and ifInErrors were not
      incrementing each time the counters they aggregate were.
      
      The Controlled Port statistic ifInErrors was not included in the output of
      macsec_get_stats64 so the value was not present in ip commands output.
      
      The ReceiveSA counters InPktsNotValid, InPktsNotUsingSA, and InPktsUnusedSA
      were not incrementing.
      Signed-off-by: NClayton Yager <Clayton_Yager@selinc.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      91ec9bd5
  5. 25 7月, 2022 5 次提交
  6. 10 6月, 2022 2 次提交
  7. 01 6月, 2022 1 次提交
    • Z
      macsec: fix UAF bug for real_dev · 196a888c
      Ziyang Xuan 提交于
      Create a new macsec device but not get reference to real_dev. That can
      not ensure that real_dev is freed after macsec. That will trigger the
      UAF bug for real_dev as following:
      
      ==================================================================
      BUG: KASAN: use-after-free in macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662
      Call Trace:
       ...
       macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662
       dev_get_iflink+0x73/0xe0 net/core/dev.c:637
       default_operstate net/core/link_watch.c:42 [inline]
       rfc2863_policy+0x233/0x2d0 net/core/link_watch.c:54
       linkwatch_do_dev+0x2a/0x150 net/core/link_watch.c:161
      
      Allocated by task 22209:
       ...
       alloc_netdev_mqs+0x98/0x1100 net/core/dev.c:10549
       rtnl_create_link+0x9d7/0xc00 net/core/rtnetlink.c:3235
       veth_newlink+0x20e/0xa90 drivers/net/veth.c:1748
      
      Freed by task 8:
       ...
       kfree+0xd6/0x4d0 mm/slub.c:4552
       kvfree+0x42/0x50 mm/util.c:615
       device_release+0x9f/0x240 drivers/base/core.c:2229
       kobject_cleanup lib/kobject.c:673 [inline]
       kobject_release lib/kobject.c:704 [inline]
       kref_put include/linux/kref.h:65 [inline]
       kobject_put+0x1c8/0x540 lib/kobject.c:721
       netdev_run_todo+0x72e/0x10b0 net/core/dev.c:10327
      
      After commit faab39f6 ("net: allow out-of-order netdev unregistration")
      and commit e5f80fcf ("ipv6: give an IPv6 dev to blackhole_netdev"), we
      can add dev_hold_track() in macsec_dev_init() and dev_put_track() in
      macsec_free_netdev() to fix the problem.
      
      Fixes: 2bce1ebe ("macsec: fix refcnt leak in module exit routine")
      Reported-by: syzbot+d0e94b65ac259c29ce7a@syzkaller.appspotmail.com
      Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com>
      Link: https://lore.kernel.org/r/20220531074500.1272846-1-william.xuanziyang@huawei.comSigned-off-by: NPaolo Abeni <pabeni@redhat.com>
      196a888c
  8. 14 2月, 2022 1 次提交
    • S
      net: dev: Makes sure netif_rx() can be invoked in any context. · baebdf48
      Sebastian Andrzej Siewior 提交于
      Dave suggested a while ago (eleven years by now) "Let's make netif_rx()
      work in all contexts and get rid of netif_rx_ni()". Eric agreed and
      pointed out that modern devices should use netif_receive_skb() to avoid
      the overhead.
      In the meantime someone added another variant, netif_rx_any_context(),
      which behaves as suggested.
      
      netif_rx() must be invoked with disabled bottom halves to ensure that
      pending softirqs, which were raised within the function, are handled.
      netif_rx_ni() can be invoked only from process context (bottom halves
      must be enabled) because the function handles pending softirqs without
      checking if bottom halves were disabled or not.
      netif_rx_any_context() invokes on the former functions by checking
      in_interrupts().
      
      netif_rx() could be taught to handle both cases (disabled and enabled
      bottom halves) by simply disabling bottom halves while invoking
      netif_rx_internal(). The local_bh_enable() invocation will then invoke
      pending softirqs only if the BH-disable counter drops to zero.
      
      Eric is concerned about the overhead of BH-disable+enable especially in
      regard to the loopback driver. As critical as this driver is, it will
      receive a shortcut to avoid the additional overhead which is not needed.
      
      Add a local_bh_disable() section in netif_rx() to ensure softirqs are
      handled if needed.
      Provide __netif_rx() which does not disable BH and has a lockdep assert
      to ensure that interrupts are disabled. Use this shortcut in the
      loopback driver and in drivers/net/*.c.
      Make netif_rx_ni() and netif_rx_any_context() invoke netif_rx() so they
      can be removed once they are no more users left.
      
      Link: https://lkml.kernel.org/r/20100415.020246.218622820.davem@davemloft.netSigned-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Reviewed-by: NEric Dumazet <edumazet@google.com>
      Reviewed-by: NToke Høiland-Jørgensen <toke@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      baebdf48
  9. 02 2月, 2022 1 次提交
  10. 01 2月, 2022 1 次提交
  11. 24 10月, 2021 1 次提交
  12. 02 10月, 2021 1 次提交
  13. 25 6月, 2021 1 次提交
  14. 04 11月, 2020 1 次提交
  15. 14 10月, 2020 1 次提交
  16. 09 10月, 2020 1 次提交
  17. 03 10月, 2020 1 次提交
  18. 19 8月, 2020 1 次提交
  19. 29 6月, 2020 1 次提交
  20. 10 6月, 2020 1 次提交
    • C
      net: change addr_list_lock back to static key · 845e0ebb
      Cong Wang 提交于
      The dynamic key update for addr_list_lock still causes troubles,
      for example the following race condition still exists:
      
      CPU 0:				CPU 1:
      (RCU read lock)			(RTNL lock)
      dev_mc_seq_show()		netdev_update_lockdep_key()
      				  -> lockdep_unregister_key()
       -> netif_addr_lock_bh()
      
      because lockdep doesn't provide an API to update it atomically.
      Therefore, we have to move it back to static keys and use subclass
      for nest locking like before.
      
      In commit 1a33e10e ("net: partially revert dynamic lockdep key
      changes"), I already reverted most parts of commit ab92d68f
      ("net: core: add generic lockdep keys").
      
      This patch reverts the rest and also part of commit f3b0a18b
      ("net: remove unnecessary variables and callback"). After this
      patch, addr_list_lock changes back to using static keys and
      subclasses to satisfy lockdep. Thanks to dev->lower_level, we do
      not have to change back to ->ndo_get_lock_subclass().
      
      And hopefully this reduces some syzbot lockdep noises too.
      
      Reported-by: syzbot+f3a0e80c34b3fc28ac5e@syzkaller.appspotmail.com
      Cc: Taehee Yoo <ap420073@gmail.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      845e0ebb
  21. 07 5月, 2020 1 次提交
  22. 05 5月, 2020 1 次提交
  23. 01 5月, 2020 1 次提交
    • S
      net: macsec: preserve ingress frame ordering · ab046a5d
      Scott Dial 提交于
      MACsec decryption always occurs in a softirq context. Since
      the FPU may not be usable in the softirq context, the call to
      decrypt may be scheduled on the cryptd work queue. The cryptd
      work queue does not provide ordering guarantees. Therefore,
      preserving order requires masking out ASYNC implementations
      of gcm(aes).
      
      For instance, an Intel CPU with AES-NI makes available the
      generic-gcm-aesni driver from the aesni_intel module to
      implement gcm(aes). However, this implementation requires
      the FPU, so it is not always available to use from a softirq
      context, and will fallback to the cryptd work queue, which
      does not preserve frame ordering. With this change, such a
      system would select gcm_base(ctr(aes-aesni),ghash-generic).
      While the aes-aesni implementation prefers to use the FPU, it
      will fallback to the aes-asm implementation if unavailable.
      
      By using a synchronous version of gcm(aes), the decryption
      will complete before returning from crypto_aead_decrypt().
      Therefore, the macsec_decrypt_done() callback will be called
      before returning from macsec_decrypt(). Thus, the order of
      calls to macsec_post_decrypt() for the frames is preserved.
      
      While it's presumable that the pure AES-NI version of gcm(aes)
      is more performant, the hybrid solution is capable of gigabit
      speeds on modest hardware. Regardless, preserving the order
      of frames is paramount for many network protocols (e.g.,
      triggering TCP retries). Within the MACsec driver itself, the
      replay protection is tripped by the out-of-order frames, and
      can cause frames to be dropped.
      
      This bug has been present in this code since it was added in
      v4.6, however it may not have been noticed since not all CPUs
      have FPU offload available. Additionally, the bug manifests
      as occasional out-of-order packets that are easily
      misattributed to other network phenomena.
      
      When this code was added in v4.6, the crypto/gcm.c code did
      not restrict selection of the ghash function based on the
      ASYNC flag. For instance, x86 CPUs with PCLMULQDQ would
      select the ghash-clmulni driver instead of ghash-generic,
      which submits to the cryptd work queue if the FPU is busy.
      However, this bug was was corrected in v4.8 by commit
      b30bdfa8, and was backported
      all the way back to the v3.14 stable branch, so this patch
      should be applicable back to the v4.6 stable branch.
      Signed-off-by: NScott Dial <scott@scottdial.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ab046a5d
  24. 25 4月, 2020 1 次提交
    • T
      macsec: avoid to set wrong mtu · 7f327080
      Taehee Yoo 提交于
      When a macsec interface is created, the mtu is calculated with the lower
      interface's mtu value.
      If the mtu of lower interface is lower than the length, which is needed
      by macsec interface, macsec's mtu value will be overflowed.
      So, if the lower interface's mtu is too low, macsec interface's mtu
      should be set to 0.
      
      Test commands:
          ip link add dummy0 mtu 10 type dummy
          ip link add macsec0 link dummy0 type macsec
          ip link show macsec0
      
      Before:
          11: macsec0@dummy0: <BROADCAST,MULTICAST,M-DOWN> mtu 4294967274
      After:
          11: macsec0@dummy0: <BROADCAST,MULTICAST,M-DOWN> mtu 0
      
      Fixes: c09440f7 ("macsec: introduce IEEE 802.1AE driver")
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7f327080
  25. 10 4月, 2020 1 次提交
    • T
      net: macsec: fix using wrong structure in macsec_changelink() · 022e9d60
      Taehee Yoo 提交于
      In the macsec_changelink(), "struct macsec_tx_sa tx_sc" is used to
      store "macsec_secy.tx_sc".
      But, the struct type of tx_sc is macsec_tx_sc, not macsec_tx_sa.
      So, the macsec_tx_sc should be used instead.
      
      Test commands:
          ip link add dummy0 type dummy
          ip link add macsec0 link dummy0 type macsec
          ip link set macsec0 type macsec encrypt off
      
      Splat looks like:
      [61119.963483][ T9335] ==================================================================
      [61119.964709][ T9335] BUG: KASAN: slab-out-of-bounds in macsec_changelink.part.34+0xb6/0x200 [macsec]
      [61119.965787][ T9335] Read of size 160 at addr ffff888020d69c68 by task ip/9335
      [61119.966699][ T9335]
      [61119.966979][ T9335] CPU: 0 PID: 9335 Comm: ip Not tainted 5.6.0+ #503
      [61119.967791][ T9335] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      [61119.968914][ T9335] Call Trace:
      [61119.969324][ T9335]  dump_stack+0x96/0xdb
      [61119.969809][ T9335]  ? macsec_changelink.part.34+0xb6/0x200 [macsec]
      [61119.970554][ T9335]  print_address_description.constprop.5+0x1be/0x360
      [61119.971294][ T9335]  ? macsec_changelink.part.34+0xb6/0x200 [macsec]
      [61119.971973][ T9335]  ? macsec_changelink.part.34+0xb6/0x200 [macsec]
      [61119.972703][ T9335]  __kasan_report+0x12a/0x170
      [61119.973323][ T9335]  ? macsec_changelink.part.34+0xb6/0x200 [macsec]
      [61119.973942][ T9335]  kasan_report+0xe/0x20
      [61119.974397][ T9335]  check_memory_region+0x149/0x1a0
      [61119.974866][ T9335]  memcpy+0x1f/0x50
      [61119.975209][ T9335]  macsec_changelink.part.34+0xb6/0x200 [macsec]
      [61119.975825][ T9335]  ? macsec_get_stats64+0x3e0/0x3e0 [macsec]
      [61119.976451][ T9335]  ? kernel_text_address+0x111/0x120
      [61119.976990][ T9335]  ? pskb_expand_head+0x25f/0xe10
      [61119.977503][ T9335]  ? stack_trace_save+0x82/0xb0
      [61119.977986][ T9335]  ? memset+0x1f/0x40
      [61119.978397][ T9335]  ? __nla_validate_parse+0x98/0x1ab0
      [61119.978936][ T9335]  ? macsec_alloc_tfm+0x90/0x90 [macsec]
      [61119.979511][ T9335]  ? __kasan_slab_free+0x111/0x150
      [61119.980021][ T9335]  ? kfree+0xce/0x2f0
      [61119.980700][ T9335]  ? netlink_trim+0x196/0x1f0
      [61119.981420][ T9335]  ? nla_memcpy+0x90/0x90
      [61119.982036][ T9335]  ? register_lock_class+0x19e0/0x19e0
      [61119.982776][ T9335]  ? memcpy+0x34/0x50
      [61119.983327][ T9335]  __rtnl_newlink+0x922/0x1270
      [ ... ]
      
      Fixes: 3cf3227a ("net: macsec: hardware offloading infrastructure")
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      022e9d60
  26. 07 4月, 2020 1 次提交
  27. 30 3月, 2020 1 次提交
  28. 27 3月, 2020 6 次提交