1. 08 9月, 2020 7 次提交
  2. 19 8月, 2020 1 次提交
  3. 14 8月, 2020 1 次提交
    • F
      netfilter: ebtables: reject bogus getopt len value · 5c04da55
      Florian Westphal 提交于
      syzkaller reports splat:
      ------------[ cut here ]------------
      Buffer overflow detected (80 < 137)!
      Call Trace:
       do_ebt_get_ctl+0x2b4/0x790 net/bridge/netfilter/ebtables.c:2317
       nf_getsockopt+0x72/0xd0 net/netfilter/nf_sockopt.c:116
       ip_getsockopt net/ipv4/ip_sockglue.c:1778 [inline]
      
      caused by a copy-to-user with a too-large "*len" value.
      This adds a argument check on *len just like in the non-compat version
      of the handler.
      
      Before the "Fixes" commit, the reproducer fails with -EINVAL as
      expected:
      1. core calls the "compat" getsockopt version
      2. compat getsockopt version detects the *len value is possibly
         in 64-bit layout (*len != compat_len)
      3. compat getsockopt version delegates everything to native getsockopt
         version
      4. native getsockopt rejects invalid *len
      
      -> compat handler only sees len == sizeof(compat_struct) for GET_ENTRIES.
      
      After the refactor, event sequence is:
      1. getsockopt calls "compat" version (len != native_len)
      2. compat version attempts to copy *len bytes, where *len is random
         value from userspace
      
      Fixes: fc66de8e ("netfilter/ebtables: clean up compat {get, set}sockopt handling")
      Reported-by: syzbot+5accb5c62faa1d346480@syzkaller.appspotmail.com
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      5c04da55
  4. 13 8月, 2020 1 次提交
    • F
      netfilter: avoid ipv6 -> nf_defrag_ipv6 module dependency · 2404b73c
      Florian Westphal 提交于
      nf_ct_frag6_gather is part of nf_defrag_ipv6.ko, not ipv6 core.
      
      The current use of the netfilter ipv6 stub indirections  causes a module
      dependency between ipv6 and nf_defrag_ipv6.
      
      This prevents nf_defrag_ipv6 module from being removed because ipv6 can't
      be unloaded.
      
      Remove the indirection and always use a direct call.  This creates a
      depency from nf_conntrack_bridge to nf_defrag_ipv6 instead:
      
      modinfo nf_conntrack
      depends:        nf_conntrack,nf_defrag_ipv6,bridge
      
      .. and nf_conntrack already depends on nf_defrag_ipv6 anyway.
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      2404b73c
  5. 04 8月, 2020 1 次提交
  6. 25 7月, 2020 2 次提交
  7. 22 7月, 2020 1 次提交
  8. 20 7月, 2020 1 次提交
  9. 15 7月, 2020 8 次提交
  10. 14 7月, 2020 1 次提交
  11. 13 7月, 2020 1 次提交
    • N
      net: bridge: notify on vlan tunnel changes done via the old api · 94339443
      Nikolay Aleksandrov 提交于
      If someone uses the old vlan API to configure tunnel mappings we'll only
      generate the old-style full port notification. That would be a problem
      if we are monitoring the new vlan notifications for changes. The patch
      resolves the issue by adding vlan notifications to the old tunnel netlink
      code. As usual we try to compress the notifications for as many vlans
      in a range as possible, thus a vlan tunnel change is considered able
      to enter the "current" vlan notification range if:
       1. vlan exists
       2. it has actually changed (curr_change == true)
       3. it passes all standard vlan notification range checks done by
          br_vlan_can_enter_range() such as option equality, id continuity etc
      
      Note that vlan tunnel changes (add/del) are considered a part of vlan
      options so only RTM_NEWVLAN notification is generated with the relevant
      information inside.
      Signed-off-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      94339443
  12. 08 7月, 2020 1 次提交
  13. 03 7月, 2020 2 次提交
  14. 30 6月, 2020 1 次提交
  15. 29 6月, 2020 1 次提交
    • H
      bridge: mrp: Fix endian conversion and some other warnings · 9b14d1f8
      Horatiu Vultur 提交于
      The following sparse warnings are fixed:
      net/bridge/br_mrp.c:106:18: warning: incorrect type in assignment (different base types)
      net/bridge/br_mrp.c:106:18:    expected unsigned short [usertype]
      net/bridge/br_mrp.c:106:18:    got restricted __be16 [usertype]
      net/bridge/br_mrp.c:281:23: warning: incorrect type in argument 1 (different modifiers)
      net/bridge/br_mrp.c:281:23:    expected struct list_head *entry
      net/bridge/br_mrp.c:281:23:    got struct list_head [noderef] *
      net/bridge/br_mrp.c:332:28: warning: incorrect type in argument 1 (different modifiers)
      net/bridge/br_mrp.c:332:28:    expected struct list_head *new
      net/bridge/br_mrp.c:332:28:    got struct list_head [noderef] *
      net/bridge/br_mrp.c:332:40: warning: incorrect type in argument 2 (different modifiers)
      net/bridge/br_mrp.c:332:40:    expected struct list_head *head
      net/bridge/br_mrp.c:332:40:    got struct list_head [noderef] *
      net/bridge/br_mrp.c:682:29: warning: incorrect type in argument 1 (different modifiers)
      net/bridge/br_mrp.c:682:29:    expected struct list_head const *head
      net/bridge/br_mrp.c:682:29:    got struct list_head [noderef] *
      Reported-by: Nkernel test robot <lkp@intel.com>
      Fixes: 2f1a11ae ("bridge: mrp: Add MRP interface.")
      Fixes: 4b8d7d4c ("bridge: mrp: Extend bridge interface")
      Fixes: 9a9f26e8 ("bridge: mrp: Connect MRP API with the switchdev API")
      Signed-off-by: NHoratiu Vultur <horatiu.vultur@microchip.com>
      Acked-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9b14d1f8
  16. 26 6月, 2020 1 次提交
  17. 25 6月, 2020 4 次提交
  18. 24 6月, 2020 1 次提交
  19. 14 6月, 2020 1 次提交
    • M
      treewide: replace '---help---' in Kconfig files with 'help' · a7f7f624
      Masahiro Yamada 提交于
      Since commit 84af7a61 ("checkpatch: kconfig: prefer 'help' over
      '---help---'"), the number of '---help---' has been gradually
      decreasing, but there are still more than 2400 instances.
      
      This commit finishes the conversion. While I touched the lines,
      I also fixed the indentation.
      
      There are a variety of indentation styles found.
      
        a) 4 spaces + '---help---'
        b) 7 spaces + '---help---'
        c) 8 spaces + '---help---'
        d) 1 space + 1 tab + '---help---'
        e) 1 tab + '---help---'    (correct indentation)
        f) 1 tab + 1 space + '---help---'
        g) 1 tab + 2 spaces + '---help---'
      
      In order to convert all of them to 1 tab + 'help', I ran the
      following commend:
      
        $ find . -name 'Kconfig*' | xargs sed -i 's/^[[:space:]]*---help---/\thelp/'
      Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      a7f7f624
  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. 03 6月, 2020 1 次提交
    • C
      mm: remove the pgprot argument to __vmalloc · 88dca4ca
      Christoph Hellwig 提交于
      The pgprot argument to __vmalloc is always PAGE_KERNEL now, so remove it.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Reviewed-by: Michael Kelley <mikelley@microsoft.com> [hyperv]
      Acked-by: Gao Xiang <xiang@kernel.org> [erofs]
      Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Acked-by: NWei Liu <wei.liu@kernel.org>
      Cc: Christian Borntraeger <borntraeger@de.ibm.com>
      Cc: Christophe Leroy <christophe.leroy@c-s.fr>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: David Airlie <airlied@linux.ie>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Haiyang Zhang <haiyangz@microsoft.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: "K. Y. Srinivasan" <kys@microsoft.com>
      Cc: Laura Abbott <labbott@redhat.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: Nitin Gupta <ngupta@vflare.org>
      Cc: Robin Murphy <robin.murphy@arm.com>
      Cc: Sakari Ailus <sakari.ailus@linux.intel.com>
      Cc: Stephen Hemminger <sthemmin@microsoft.com>
      Cc: Sumit Semwal <sumit.semwal@linaro.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Paul Mackerras <paulus@ozlabs.org>
      Cc: Vasily Gorbik <gor@linux.ibm.com>
      Cc: Will Deacon <will@kernel.org>
      Link: http://lkml.kernel.org/r/20200414131348.444715-22-hch@lst.deSigned-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      88dca4ca
  22. 02 6月, 2020 1 次提交
    • H
      bridge: mrp: Add support for role MRA · c6676e7d
      Horatiu Vultur 提交于
      A node that has the MRA role, it can behave as MRM or MRC.
      
      Initially it starts as MRM and sends MRP_Test frames on both ring ports.
      If it detects that there are MRP_Test send by another MRM, then it
      checks if these frames have a lower priority than itself. In this case
      it would send MRP_Nack frames to notify the other node that it needs to
      stop sending MRP_Test frames.
      If it receives a MRP_Nack frame then it stops sending MRP_Test frames
      and starts to behave as a MRC but it would continue to monitor the
      MRP_Test frames send by MRM. If at a point the MRM stops to send
      MRP_Test frames it would get the MRM role and start to send MRP_Test
      frames.
      Signed-off-by: NHoratiu Vultur <horatiu.vultur@microchip.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c6676e7d