1. 01 8月, 2019 1 次提交
    • J
      IB/mad: Fix use-after-free in ib mad completion handling · 770b7d96
      Jack Morgenstein 提交于
      We encountered a use-after-free bug when unloading the driver:
      
      [ 3562.116059] BUG: KASAN: use-after-free in ib_mad_post_receive_mads+0xddc/0xed0 [ib_core]
      [ 3562.117233] Read of size 4 at addr ffff8882ca5aa868 by task kworker/u13:2/23862
      [ 3562.118385]
      [ 3562.119519] CPU: 2 PID: 23862 Comm: kworker/u13:2 Tainted: G           OE     5.1.0-for-upstream-dbg-2019-05-19_16-44-30-13 #1
      [ 3562.121806] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu2 04/01/2014
      [ 3562.123075] Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core]
      [ 3562.124383] Call Trace:
      [ 3562.125640]  dump_stack+0x9a/0xeb
      [ 3562.126911]  print_address_description+0xe3/0x2e0
      [ 3562.128223]  ? ib_mad_post_receive_mads+0xddc/0xed0 [ib_core]
      [ 3562.129545]  __kasan_report+0x15c/0x1df
      [ 3562.130866]  ? ib_mad_post_receive_mads+0xddc/0xed0 [ib_core]
      [ 3562.132174]  kasan_report+0xe/0x20
      [ 3562.133514]  ib_mad_post_receive_mads+0xddc/0xed0 [ib_core]
      [ 3562.134835]  ? find_mad_agent+0xa00/0xa00 [ib_core]
      [ 3562.136158]  ? qlist_free_all+0x51/0xb0
      [ 3562.137498]  ? mlx4_ib_sqp_comp_worker+0x1970/0x1970 [mlx4_ib]
      [ 3562.138833]  ? quarantine_reduce+0x1fa/0x270
      [ 3562.140171]  ? kasan_unpoison_shadow+0x30/0x40
      [ 3562.141522]  ib_mad_recv_done+0xdf6/0x3000 [ib_core]
      [ 3562.142880]  ? _raw_spin_unlock_irqrestore+0x46/0x70
      [ 3562.144277]  ? ib_mad_send_done+0x1810/0x1810 [ib_core]
      [ 3562.145649]  ? mlx4_ib_destroy_cq+0x2a0/0x2a0 [mlx4_ib]
      [ 3562.147008]  ? _raw_spin_unlock_irqrestore+0x46/0x70
      [ 3562.148380]  ? debug_object_deactivate+0x2b9/0x4a0
      [ 3562.149814]  __ib_process_cq+0xe2/0x1d0 [ib_core]
      [ 3562.151195]  ib_cq_poll_work+0x45/0xf0 [ib_core]
      [ 3562.152577]  process_one_work+0x90c/0x1860
      [ 3562.153959]  ? pwq_dec_nr_in_flight+0x320/0x320
      [ 3562.155320]  worker_thread+0x87/0xbb0
      [ 3562.156687]  ? __kthread_parkme+0xb6/0x180
      [ 3562.158058]  ? process_one_work+0x1860/0x1860
      [ 3562.159429]  kthread+0x320/0x3e0
      [ 3562.161391]  ? kthread_park+0x120/0x120
      [ 3562.162744]  ret_from_fork+0x24/0x30
      ...
      [ 3562.187615] Freed by task 31682:
      [ 3562.188602]  save_stack+0x19/0x80
      [ 3562.189586]  __kasan_slab_free+0x11d/0x160
      [ 3562.190571]  kfree+0xf5/0x2f0
      [ 3562.191552]  ib_mad_port_close+0x200/0x380 [ib_core]
      [ 3562.192538]  ib_mad_remove_device+0xf0/0x230 [ib_core]
      [ 3562.193538]  remove_client_context+0xa6/0xe0 [ib_core]
      [ 3562.194514]  disable_device+0x14e/0x260 [ib_core]
      [ 3562.195488]  __ib_unregister_device+0x79/0x150 [ib_core]
      [ 3562.196462]  ib_unregister_device+0x21/0x30 [ib_core]
      [ 3562.197439]  mlx4_ib_remove+0x162/0x690 [mlx4_ib]
      [ 3562.198408]  mlx4_remove_device+0x204/0x2c0 [mlx4_core]
      [ 3562.199381]  mlx4_unregister_interface+0x49/0x1d0 [mlx4_core]
      [ 3562.200356]  mlx4_ib_cleanup+0xc/0x1d [mlx4_ib]
      [ 3562.201329]  __x64_sys_delete_module+0x2d2/0x400
      [ 3562.202288]  do_syscall_64+0x95/0x470
      [ 3562.203277]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      The problem was that the MAD PD was deallocated before the MAD CQ.
      There was completion work pending for the CQ when the PD got deallocated.
      When the mad completion handling reached procedure
      ib_mad_post_receive_mads(), we got a use-after-free bug in the following
      line of code in that procedure:
         sg_list.lkey = qp_info->port_priv->pd->local_dma_lkey;
      (the pd pointer in the above line is no longer valid, because the
      pd has been deallocated).
      
      We fix this by allocating the PD before the CQ in procedure
      ib_mad_port_open(), and deallocating the PD after freeing the CQ
      in procedure ib_mad_port_close().
      
      Since the CQ completion work queue is flushed during ib_free_cq(),
      no completions will be pending for that CQ when the PD is later
      deallocated.
      
      Note that freeing the CQ before deallocating the PD is the practice
      in the ULPs.
      
      Fixes: 4be90bc6 ("IB/mad: Remove ib_get_dma_mr calls")
      Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Link: https://lore.kernel.org/r/20190801121449.24973-1-leon@kernel.orgSigned-off-by: NDoug Ledford <dledford@redhat.com>
      770b7d96
  2. 28 3月, 2019 4 次提交
  3. 26 3月, 2019 1 次提交
  4. 20 2月, 2019 1 次提交
  5. 12 12月, 2018 1 次提交
  6. 17 10月, 2018 1 次提交
  7. 07 9月, 2018 2 次提交
  8. 06 9月, 2018 1 次提交
  9. 25 7月, 2018 1 次提交
  10. 19 6月, 2018 3 次提交
  11. 01 6月, 2018 2 次提交
  12. 01 5月, 2018 1 次提交
  13. 23 12月, 2017 1 次提交
  14. 11 11月, 2017 1 次提交
    • P
      IB/core: Avoid crash on pkey enforcement failed in received MADs · 89548bca
      Parav Pandit 提交于
      Below kernel crash is observed when Pkey security enforcement fails on
      received MADs. This issue is reported in [1].
      
      ib_free_recv_mad() accesses the rmpp_list, whose initialization is
      needed before accessing it.
      When security enformcent fails on received MADs, MAD processing avoided
      due to security checks failed.
      
      OpenSM[3770]: SM port is down
      kernel: BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
      kernel: IP: ib_free_recv_mad+0x44/0xa0 [ib_core]
      kernel: PGD 0
      kernel: P4D 0
      kernel:
      kernel: Oops: 0002 [#1] SMP
      kernel: CPU: 0 PID: 2833 Comm: kworker/0:1H Tainted: P          IO    4.13.4-1-pve #1
      kernel: Hardware name: Dell       XS23-TY3        /9CMP63, BIOS 1.71 09/17/2013
      kernel: Workqueue: ib-comp-wq ib_cq_poll_work [ib_core]
      kernel: task: ffffa069c6541600 task.stack: ffffb9a729054000
      kernel: RIP: 0010:ib_free_recv_mad+0x44/0xa0 [ib_core]
      kernel: RSP: 0018:ffffb9a729057d38 EFLAGS: 00010286
      kernel: RAX: ffffa069cb138a48 RBX: ffffa069cb138a10 RCX: 0000000000000000
      kernel: RDX: ffffb9a729057d38 RSI: 0000000000000000 RDI: ffffa069cb138a20
      kernel: RBP: ffffb9a729057d60 R08: ffffa072d2d49800 R09: ffffa069cb138ae0
      kernel: R10: ffffa069cb138ae0 R11: ffffa072b3994e00 R12: ffffb9a729057d38
      kernel: R13: ffffa069d1c90000 R14: 0000000000000000 R15: ffffa069d1c90880
      kernel: FS:  0000000000000000(0000) GS:ffffa069dba00000(0000) knlGS:0000000000000000
      kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      kernel: CR2: 0000000000000008 CR3: 00000011f51f2000 CR4: 00000000000006f0
      kernel: Call Trace:
      kernel:  ib_mad_recv_done+0x5cc/0xb50 [ib_core]
      kernel:  __ib_process_cq+0x5c/0xb0 [ib_core]
      kernel:  ib_cq_poll_work+0x20/0x60 [ib_core]
      kernel:  process_one_work+0x1e9/0x410
      kernel:  worker_thread+0x4b/0x410
      kernel:  kthread+0x109/0x140
      kernel:  ? process_one_work+0x410/0x410
      kernel:  ? kthread_create_on_node+0x70/0x70
      kernel:  ? SyS_exit_group+0x14/0x20
      kernel:  ret_from_fork+0x25/0x30
      kernel: RIP: ib_free_recv_mad+0x44/0xa0 [ib_core] RSP: ffffb9a729057d38
      kernel: CR2: 0000000000000008
      
      [1] : https://www.spinics.net/lists/linux-rdma/msg56190.html
      
      Fixes: 47a2b338 ("IB/core: Enforce security on management datagrams")
      Cc: stable@vger.kernel.org # 4.13+
      Signed-off-by: NParav Pandit <parav@mellanox.com>
      Reported-by: NChris Blake <chrisrblake93@gmail.com>
      Reviewed-by: NDaniel Jurgens <danielj@mellanox.com>
      Reviewed-by: NHal Rosenstock <hal@mellanox.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      89548bca
  15. 24 5月, 2017 1 次提交
    • D
      IB/core: Enforce security on management datagrams · 47a2b338
      Daniel Jurgens 提交于
      Allocate and free a security context when creating and destroying a MAD
      agent.  This context is used for controlling access to PKeys and sending
      and receiving SMPs.
      
      When sending or receiving a MAD check that the agent has permission to
      access the PKey for the Subnet Prefix of the port.
      
      During MAD and snoop agent registration for SMI QPs check that the
      calling process has permission to access the manage the subnet  and
      register a callback with the LSM to be notified of policy changes. When
      notificaiton of a policy change occurs recheck permission and set a flag
      indicating sending and receiving SMPs is allowed.
      
      When sending and receiving MADs check that the agent has access to the
      SMI if it's on an SMI QP.  Because security policy can change it's
      possible permission was allowed when creating the agent, but no longer
      is.
      Signed-off-by: NDaniel Jurgens <danielj@mellanox.com>
      Acked-by: NDoug Ledford <dledford@redhat.com>
      [PM: remove the LSM hook init code]
      Signed-off-by: NPaul Moore <paul@paul-moore.com>
      47a2b338
  16. 02 5月, 2017 3 次提交
  17. 26 4月, 2017 1 次提交
  18. 25 1月, 2017 1 次提交
  19. 15 12月, 2016 2 次提交
  20. 04 12月, 2016 1 次提交
  21. 08 10月, 2016 1 次提交
  22. 24 9月, 2016 1 次提交
  23. 07 6月, 2016 1 次提交
  24. 25 5月, 2016 1 次提交
  25. 20 1月, 2016 2 次提交
  26. 24 12月, 2015 1 次提交
    • D
      IB/mad: Ensure fairness in ib_mad_completion_handler · 0d6ed314
      Dean Luick 提交于
      It was found that when a process was rapidly sending MADs other processes could
      be hung in their unregister calls.
      
      This would happen when process A was injecting packets fast enough that the
      single threaded workqueue was never exiting ib_mad_completion_handler.
      Therefore when process B called flush_workqueue via the unregister call it
      would hang until process A stopped sending MADs.
      
      The fix is to periodically reschedule ib_mad_completion_handler after
      processing a large number of completions.  The number of completions chosen was
      decided based on the defaults for the recv queue size.  However, it was kept
      fixed such that increasing those queue sizes would not adversely affect
      fairness in the future.
      Reviewed-by: NIra Weiny <ira.weiny@intel.com>
      Signed-off-by: NDean Luick <dean.luick@intel.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      0d6ed314
  27. 09 12月, 2015 1 次提交
    • H
      IB/mad: Require CM send method for everything except ClassPortInfo · 53370886
      Hal Rosenstock 提交于
      Receipt of CM MAD with other than the Send method for an attribute
      other than the ClassPortInfo attribute is invalid.
      
      CM attributes other than ClassPortInfo only use the send method.
      
      The SRP initiator does not maintain a timeout policy for CM connect
      requests relies on the CM layer to do that. The result was that
      the SRP initiator hung as the connect request never completed.
      
      A new SRP target has been observed to respond to Send CM REQ
      with GetResp of CM REQ with bad status. This is non conformant
      with IBA spec but exposes a vulnerability in the current MAD/CM
      code which will respond to the incoming GetResp of CM REQ as if
      it was a valid incoming Send of CM REQ rather than tossing
      this on the floor. It also causes the MAD layer not to
      retransmit the original REQ even though it has not received a REP.
      Reviewed-by: NSagi Grimberg <sagig@mellanox.com>
      Signed-off-by: NHal Rosenstock <hal@mellanox.com>
      Reviewed-by: NIra Weiny <ira.weiny@intel.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      53370886
  28. 22 10月, 2015 1 次提交
  29. 08 10月, 2015 1 次提交
    • C
      IB: split struct ib_send_wr · e622f2f4
      Christoph Hellwig 提交于
      This patch split up struct ib_send_wr so that all non-trivial verbs
      use their own structure which embedds struct ib_send_wr.  This dramaticly
      shrinks the size of a WR for most common operations:
      
      sizeof(struct ib_send_wr) (old):	96
      
      sizeof(struct ib_send_wr):		48
      sizeof(struct ib_rdma_wr):		64
      sizeof(struct ib_atomic_wr):		96
      sizeof(struct ib_ud_wr):		88
      sizeof(struct ib_fast_reg_wr):		88
      sizeof(struct ib_bind_mw_wr):		96
      sizeof(struct ib_sig_handover_wr):	80
      
      And with Sagi's pending MR rework the fast registration WR will also be
      down to a reasonable size:
      
      sizeof(struct ib_fastreg_wr):		64
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: Bart Van Assche <bart.vanassche@sandisk.com> [srp, srpt]
      Reviewed-by: Chuck Lever <chuck.lever@oracle.com> [sunrpc]
      Tested-by: NHaggai Eran <haggaie@mellanox.com>
      Tested-by: NSagi Grimberg <sagig@mellanox.com>
      Tested-by: NSteve Wise <swise@opengridcomputing.com>
      e622f2f4