1. 11 10月, 2018 2 次提交
    • F
      xfrm: policy: use hlist rcu variants on insert · 9dffff20
      Florian Westphal 提交于
      bydst table/list lookups use rcu, so insertions must use rcu versions.
      
      Fixes: a7c44247 ("xfrm: policy: make xfrm_policy_lookup_bytype lockless")
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      9dffff20
    • A
      net/xfrm: fix out-of-bounds packet access · 9f7e43da
      Alexei Starovoitov 提交于
      BUG: KASAN: slab-out-of-bounds in _decode_session6+0x1331/0x14e0
      net/ipv6/xfrm6_policy.c:161
      Read of size 1 at addr ffff8801d882eec7 by task syz-executor1/6667
      Call Trace:
        __dump_stack lib/dump_stack.c:77 [inline]
        dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
        print_address_description+0x6c/0x20b mm/kasan/report.c:256
        kasan_report_error mm/kasan/report.c:354 [inline]
        kasan_report.cold.7+0x242/0x30d mm/kasan/report.c:412
        __asan_report_load1_noabort+0x14/0x20 mm/kasan/report.c:430
        _decode_session6+0x1331/0x14e0 net/ipv6/xfrm6_policy.c:161
        __xfrm_decode_session+0x71/0x140 net/xfrm/xfrm_policy.c:2299
        xfrm_decode_session include/net/xfrm.h:1232 [inline]
        vti6_tnl_xmit+0x3c3/0x1bc1 net/ipv6/ip6_vti.c:542
        __netdev_start_xmit include/linux/netdevice.h:4313 [inline]
        netdev_start_xmit include/linux/netdevice.h:4322 [inline]
        xmit_one net/core/dev.c:3217 [inline]
        dev_hard_start_xmit+0x272/0xc10 net/core/dev.c:3233
        __dev_queue_xmit+0x2ab2/0x3870 net/core/dev.c:3803
        dev_queue_xmit+0x17/0x20 net/core/dev.c:3836
      
      Reported-by: syzbot+acffccec848dc13fe459@syzkaller.appspotmail.com
      Reported-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      9f7e43da
  2. 04 10月, 2018 1 次提交
  3. 02 10月, 2018 7 次提交
    • L
      xfrm: fix gro_cells leak when remove virtual xfrm interfaces · 4da40259
      Li RongQing 提交于
      The device gro_cells has been initialized, it should be freed,
      otherwise it will be leaked
      
      Fixes: f203b76d ("xfrm: Add virtual xfrm interfaces")
      Signed-off-by: NZhang Yu <zhangyu31@baidu.com>
      Signed-off-by: NLi RongQing <lirongqing@baidu.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      4da40259
    • D
      Merge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth · 92d7c74b
      David S. Miller 提交于
      Johan Hedberg says:
      
      ====================
      pull request: bluetooth 2018-09-27
      
      Here's one more Bluetooth fix for 4.19, fixing the handling of an
      attempt to unpair a device while pairing is in progress.
      
      Let me know if there are any issues pulling. Thanks.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      92d7c74b
    • L
      tipc: ignore STATE_MSG on wrong link session · d949cfed
      LUU Duc Canh 提交于
      The initial session number when a link is created is based on a random
      value, taken from struct tipc_net->random. It is then incremented for
      each link reset to avoid mixing protocol messages from different link
      sessions.
      
      However, when a bearer is reset all its links are deleted, and will
      later be re-created using the same random value as the first time.
      This means that if the link never went down between creation and
      deletion we will still sometimes have two subsequent sessions with
      the same session number. In virtual environments with potentially
      long transmission times this has turned out to be a real problem.
      
      We now fix this by randomizing the session number each time a link
      is created.
      
      With a session number size of 16 bits this gives a risk of session
      collision of 1/64k. To reduce this further, we also introduce a sanity
      check on the very first STATE message arriving at a link. If this has
      an acknowledge value differing from 0, which is logically impossible,
      we ignore the message. The final risk for session collision is hence
      reduced to 1/4G, which should be sufficient.
      Signed-off-by: NLUU Duc Canh <canh.d.luu@dektech.com.au>
      Signed-off-by: NJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d949cfed
    • D
      net: sched: act_ipt: check for underflow in __tcf_ipt_init() · aeadd93f
      Dan Carpenter 提交于
      If "td->u.target_size" is larger than sizeof(struct xt_entry_target) we
      return -EINVAL.  But we don't check whether it's smaller than
      sizeof(struct xt_entry_target) and that could lead to an out of bounds
      read.
      
      Fixes: 7ba699c6 ("[NET_SCHED]: Convert actions from rtnetlink to new netlink API")
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      aeadd93f
    • D
      Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec · ee0b6f48
      David S. Miller 提交于
      Steffen Klassert says:
      
      ====================
      pull request (net): ipsec 2018-10-01
      
      1) Validate address prefix lengths in the xfrm selector,
         otherwise we may hit undefined behaviour in the
         address matching functions if the prefix is too
         big for the given address family.
      
      2) Fix skb leak on local message size errors.
         From Thadeu Lima de Souza Cascardo.
      
      3) We currently reset the transport header back to the network
         header after a transport mode transformation is applied. This
         leads to an incorrect transport header when multiple transport
         mode transformations are applied. Reset the transport header
         only after all transformations are already applied to fix this.
         From Sowmini Varadhan.
      
      4) We only support one offloaded xfrm, so reset crypto_done after
         the first transformation in xfrm_input(). Otherwise we may call
         the wrong input method for subsequent transformations.
         From Sowmini Varadhan.
      
      5) Fix NULL pointer dereference when skb_dst_force clears the dst_entry.
         skb_dst_force does not really force a dst refcount anymore, it might
         clear it instead. xfrm code did not expect this, add a check to not
         dereference skb_dst() if it was cleared by skb_dst_force.
      
      6) Validate xfrm template mode, otherwise we can get a stack-out-of-bounds
         read in xfrm_state_find. From Sean Tranchetti.
      
      Please pull or let me know if there are problems.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ee0b6f48
    • E
      tcp/dccp: fix lockdep issue when SYN is backlogged · 1ad98e9d
      Eric Dumazet 提交于
      In normal SYN processing, packets are handled without listener
      lock and in RCU protected ingress path.
      
      But syzkaller is known to be able to trick us and SYN
      packets might be processed in process context, after being
      queued into socket backlog.
      
      In commit 06f877d6 ("tcp/dccp: fix other lockdep splats
      accessing ireq_opt") I made a very stupid fix, that happened
      to work mostly because of the regular path being RCU protected.
      
      Really the thing protecting ireq->ireq_opt is RCU read lock,
      and the pseudo request refcnt is not relevant.
      
      This patch extends what I did in commit 449809a6 ("tcp/dccp:
      block BH for SYN processing") by adding an extra rcu_read_{lock|unlock}
      pair in the paths that might be taken when processing SYN from
      socket backlog (thus possibly in process context)
      
      Fixes: 06f877d6 ("tcp/dccp: fix other lockdep splats accessing ireq_opt")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1ad98e9d
    • D
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf · c8424ddd
      David S. Miller 提交于
      Pablo Neira Ayuso says:
      
      ====================
      Netfilter fixes for net
      
      The following patchset contains Netfilter fixes for your net tree:
      
      1) Skip ip_sabotage_in() for packet making into the VRF driver,
         otherwise packets are dropped, from David Ahern.
      
      2) Clang compilation warning uncovering typo in the
         nft_validate_register_store() call from nft_osf, from Stefan Agner.
      
      3) Double sizeof netlink message length calculations in ctnetlink,
         from zhong jiang.
      
      4) Missing rb_erase() on batch full in rbtree garbage collector,
         from Taehee Yoo.
      
      5) Calm down compilation warning in nf_hook(), from Florian Westphal.
      
      6) Missing check for non-null sk in xt_socket before validating
         netns procedence, from Flavio Leitner.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c8424ddd
  4. 30 9月, 2018 14 次提交
  5. 29 9月, 2018 16 次提交
    • D
      Merge branch 'netpoll-second-round-of-fixes' · f13d1b48
      David S. Miller 提交于
      Eric Dumazet says:
      
      ====================
      netpoll: second round of fixes.
      
      As diagnosed by Song Liu, ndo_poll_controller() can
      be very dangerous on loaded hosts, since the cpu
      calling ndo_poll_controller() might steal all NAPI
      contexts (for all RX/TX queues of the NIC).
      
      This capture, showing one ksoftirqd eating all cycles
      can last for unlimited amount of time, since one
      cpu is generally not able to drain all the queues under load.
      
      It seems that all networking drivers that do use NAPI
      for their TX completions, should not provide a ndo_poll_controller() :
      
      Most NAPI drivers have netpoll support already handled
      in core networking stack, since netpoll_poll_dev()
      uses poll_napi(dev) to iterate through registered
      NAPI contexts for a device.
      
      First patch is a fix in poll_one_napi().
      
      Then following patches take care of ten drivers.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f13d1b48
    • E
      ibmvnic: remove ndo_poll_controller · 0c3b9d1b
      Eric Dumazet 提交于
      As diagnosed by Song Liu, ndo_poll_controller() can
      be very dangerous on loaded hosts, since the cpu
      calling ndo_poll_controller() might steal all NAPI
      contexts (for all RX/TX queues of the NIC). This capture
      can last for unlimited amount of time, since one
      cpu is generally not able to drain all the queues under load.
      
      ibmvnic uses NAPI for TX completions, so we better let core
      networking stack call the napi->poll() to avoid the capture.
      
      ibmvnic_netpoll_controller() was completely wrong anyway,
      as it was scheduling NAPI to service RX queues (instead of TX),
      so I doubt netpoll ever worked on this driver.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
      Cc: John Allen <jallen@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0c3b9d1b
    • E
      sfc-falcon: remove ndo_poll_controller · a4f570be
      Eric Dumazet 提交于
      As diagnosed by Song Liu, ndo_poll_controller() can
      be very dangerous on loaded hosts, since the cpu
      calling ndo_poll_controller() might steal all NAPI
      contexts (for all RX/TX queues of the NIC). This capture
      can last for unlimited amount of time, since one
      cpu is generally not able to drain all the queues under load.
      
      sfc-falcon uses NAPI for TX completions, so we better let core
      networking stack call the napi->poll() to avoid the capture.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Solarflare linux maintainers <linux-net-drivers@solarflare.com>
      Cc: Edward Cree <ecree@solarflare.com>
      Cc: Bert Kenward <bkenward@solarflare.com>
      Acked-By: NBert Kenward <bkenward@solarflare.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a4f570be
    • E
      sfc: remove ndo_poll_controller · 9447a10f
      Eric Dumazet 提交于
      As diagnosed by Song Liu, ndo_poll_controller() can
      be very dangerous on loaded hosts, since the cpu
      calling ndo_poll_controller() might steal all NAPI
      contexts (for all RX/TX queues of the NIC). This capture
      can last for unlimited amount of time, since one
      cpu is generally not able to drain all the queues under load.
      
      sfc uses NAPI for TX completions, so we better let core
      networking stack call the napi->poll() to avoid the capture.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Edward Cree <ecree@solarflare.com>
      Cc: Bert Kenward <bkenward@solarflare.com>
      Cc: Solarflare linux maintainers <linux-net-drivers@solarflare.com>
      Acked-By: NBert Kenward <bkenward@solarflare.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9447a10f
    • E
      net: ena: remove ndo_poll_controller · 21627982
      Eric Dumazet 提交于
      As diagnosed by Song Liu, ndo_poll_controller() can
      be very dangerous on loaded hosts, since the cpu
      calling ndo_poll_controller() might steal all NAPI
      contexts (for all RX/TX queues of the NIC). This capture
      can last for unlimited amount of time, since one
      cpu is generally not able to drain all the queues under load.
      
      ena uses NAPI for TX completions, so we better let core
      networking stack call the napi->poll() to avoid the capture.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Netanel Belgazal <netanel@amazon.com>
      Cc: Saeed Bishara <saeedb@amazon.com>
      Cc: Zorik Machulsky <zorik@amazon.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      21627982
    • E
      qlogic: netxen: remove ndo_poll_controller · 3548fcf7
      Eric Dumazet 提交于
      As diagnosed by Song Liu, ndo_poll_controller() can
      be very dangerous on loaded hosts, since the cpu
      calling ndo_poll_controller() might steal all NAPI
      contexts (for all RX/TX queues of the NIC). This capture
      can last for unlimited amount of time, since one
      cpu is generally not able to drain all the queues under load.
      
      netxen uses NAPI for TX completions, so we better let core
      networking stack call the napi->poll() to avoid the capture.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Manish Chopra <manish.chopra@cavium.com>
      Cc: Rahul Verma <rahul.verma@cavium.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3548fcf7
    • E
      qlcnic: remove ndo_poll_controller · 81b059b2
      Eric Dumazet 提交于
      As diagnosed by Song Liu, ndo_poll_controller() can
      be very dangerous on loaded hosts, since the cpu
      calling ndo_poll_controller() might steal all NAPI
      contexts (for all RX/TX queues of the NIC). This capture
      can last for unlimited amount of time, since one
      cpu is generally not able to drain all the queues under load.
      
      qlcnic uses NAPI for TX completions, so we better let core
      networking stack call the napi->poll() to avoid the capture.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Harish Patil <harish.patil@cavium.com>
      Cc: Manish Chopra <manish.chopra@cavium.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      81b059b2
    • E
      virtio_net: remove ndo_poll_controller · 260dd2c3
      Eric Dumazet 提交于
      As diagnosed by Song Liu, ndo_poll_controller() can
      be very dangerous on loaded hosts, since the cpu
      calling ndo_poll_controller() might steal all NAPI
      contexts (for all RX/TX queues of the NIC). This capture
      can last for unlimited amount of time, since one
      cpu is generally not able to drain all the queues under load.
      
      virto_net uses NAPI for TX completions, so we better let core
      networking stack call the napi->poll() to avoid the capture.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: "Michael S. Tsirkin" <mst@redhat.com>
      Cc: Jason Wang <jasowang@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      260dd2c3
    • E
      net: hns: remove ndo_poll_controller · 4bd2c03b
      Eric Dumazet 提交于
      As diagnosed by Song Liu, ndo_poll_controller() can
      be very dangerous on loaded hosts, since the cpu
      calling ndo_poll_controller() might steal all NAPI
      contexts (for all RX/TX queues of the NIC). This capture
      can last for unlimited amount of time, since one
      cpu is generally not able to drain all the queues under load.
      
      hns uses NAPI for TX completions, so we better let core
      networking stack call the napi->poll() to avoid the capture.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Yisen Zhuang <yisen.zhuang@huawei.com>
      Cc: Salil Mehta <salil.mehta@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4bd2c03b
    • E
      ehea: remove ndo_poll_controller · 226a2dd6
      Eric Dumazet 提交于
      As diagnosed by Song Liu, ndo_poll_controller() can
      be very dangerous on loaded hosts, since the cpu
      calling ndo_poll_controller() might steal all NAPI
      contexts (for all RX/TX queues of the NIC). This capture
      can last for unlimited amount of time, since one
      cpu is generally not able to drain all the queues under load.
      
      ehea uses NAPI for TX completions, so we better let core
      networking stack call the napi->poll() to avoid the capture.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Douglas Miller <dougmill@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      226a2dd6
    • E
      hinic: remove ndo_poll_controller · e71fb423
      Eric Dumazet 提交于
      As diagnosed by Song Liu, ndo_poll_controller() can
      be very dangerous on loaded hosts, since the cpu
      calling ndo_poll_controller() might steal all NAPI
      contexts (for all RX/TX queues of the NIC). This capture
      can last for unlimited amount of time, since one
      cpu is generally not able to drain all the queues under load.
      
      hinic uses NAPI for TX completions, so we better let core
      networking stack call the napi->poll() to avoid the capture.
      
      Note that hinic_netpoll() was incorrectly scheduling NAPI
      on both RX and TX queues.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Aviad Krawczyk <aviad.krawczyk@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e71fb423
    • E
      netpoll: do not test NAPI_STATE_SCHED in poll_one_napi() · c24498c6
      Eric Dumazet 提交于
      Since we do no longer require NAPI drivers to provide
      an ndo_poll_controller(), napi_schedule() has not been done
      before poll_one_napi() invocation.
      
      So testing NAPI_STATE_SCHED is likely to cause early returns.
      
      While we are at it, remove outdated comment.
      
      Note to future bisections : This change might surface prior
      bugs in drivers. See commit 73f21c65 ("bnxt_en: Fix TX
      timeout during netpoll.") for one occurrence.
      
      Fixes: ac3d9dd0 ("netpoll: make ndo_poll_controller() optional")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Tested-by: NSong Liu <songliubraving@fb.com>
      Cc: Michael Chan <michael.chan@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c24498c6
    • D
      Merge tag 'mac80211-for-davem-2018-09-27' of... · 05c5e9ff
      David S. Miller 提交于
      Merge tag 'mac80211-for-davem-2018-09-27' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
      
      Johannes Berg says:
      
      ====================
      More patches than I'd like perhaps, but each seems reasonable:
       * two new spectre-v1 mitigations in nl80211
       * TX status fix in general, and mesh in particular
       * powersave vs. offchannel fix
       * regulatory initialization fix
       * fix for a queue hang due to a bad return value
       * allocate TXQs for active monitor interfaces, fixing my
         earlier patch to avoid unnecessary allocations where I
         missed this case needed them
       * fix TDLS data frames priority assignment
       * fix scan results processing to take into account duplicate
         channel numbers (over different operating classes, but we
         don't necessarily know the operating class)
       * various hwsim fixes for radio destruction and new radio
         announcement messages
       * remove an extraneous kernel-doc line
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      05c5e9ff
    • S
      qed: Fix shmem structure inconsistency between driver and the mfw. · 5f672090
      Sudarsana Reddy Kalluru 提交于
      The structure shared between driver and the management FW (mfw) differ in
      sizes. This would lead to issues when driver try to access the structure
      members which are not-aligned with the mfw copy e.g., data_ptr usage in the
      case of mfw_tlv request.
      Align the driver structure with mfw copy, add reserved field(s) to driver
      structure for the members not used by the driver.
      
      Fixes: dd006921 ("qed: Add MFW interfaces for TLV request support.)
      Signed-off-by: NSudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
      Signed-off-by: NMichal Kalderon <Michal.Kalderon@cavium.com>
      5f672090
    • S
    • S
      MAINTAINERS: change bridge maintainers · ce7d17d6
      Stephen Hemminger 提交于
      I haven't been doing reviews only but not active development on bridge
      code for several years. Roopa and Nikolay have been doing most of
      the new features and have agreed to take over as new co-maintainers.
      Signed-off-by: NStephen Hemminger <stephen@networkplumber.org>
      Acked-by: NRoopa Prabhu <roopa@cumulusnetworks.com>
      Acked-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      ce7d17d6