1. 09 8月, 2017 6 次提交
  2. 20 7月, 2017 3 次提交
  3. 18 7月, 2017 4 次提交
  4. 17 7月, 2017 3 次提交
    • M
      IB/core: Don't resolve IP address to the loopback device · cbd09aeb
      Moni Shoua 提交于
      When resolving an IP address that is on the host of the caller the
      result from querying the routing table is the loopback device. This is
      not a valid response, because it doesn't represent the RDMA device and
      the port.
      
      Therefore, callers need to check the resolved device and if it is a
      loopback device find an alternative way to resolve it. To avoid this we
      make sure that the response from rdma_resolve_ip() will not be the
      loopback device.
      
      While that, we fix an static checker warning about dereferencing an
      unintitialized pointer using the same solution as in commit abeffce9
      ("net/mlx5e: Fix a -Wmaybe-uninitialized warning") as a reference.
      Signed-off-by: NMoni Shoua <monis@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leon@kernel.org>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      cbd09aeb
    • M
      IB/core: Namespace is mandatory input for address resolution · bebb2a47
      Moni Shoua 提交于
      In function addr_resolve() the namespace is a required input parameter
      and not an output. It is passed later for searching the routing table
      and device addresses. Also, it shouldn't be copied back to the caller.
      
      Fixes: 565edd1d ('IB/addr: Pass network namespace as a parameter')
      Cc: <stable@vger.kernel.org> # v4.3+
      Signed-off-by: NMoni Shoua <monis@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leon@kernel.org>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      bebb2a47
    • G
      RDMA/core: Document confusing code · 28b5b3a2
      Gustavo A. R. Silva 提交于
      While looking into Coverity ID 1351047 I ran into the following
      piece of code at
      drivers/infiniband/core/verbs.c:496:
      
      ret = rdma_addr_find_l2_eth_by_grh(&dgid, &sgid,
                                         ah_attr->dmac,
                                         wc->wc_flags & IB_WC_WITH_VLAN ?
                                         NULL : &vlan_id,
                                         &if_index, &hoplimit);
      
      The issue here is that the position of arguments in the call to
      rdma_addr_find_l2_eth_by_grh() function do not match the order of
      the parameters:
      
      &dgid is passed to sgid
      &sgid is passed to dgid
      
      This is the function prototype:
      
      int rdma_addr_find_l2_eth_by_grh(const union ib_gid *sgid,
       				 const union ib_gid *dgid,
       				 u8 *dmac, u16 *vlan_id, int *if_index,
       				 int *hoplimit)
      
      My question here is if this is intentional?
      
      Answer:
      Yes. ib_init_ah_from_wc() creates ah from the incoming packet.
      Incoming packet has dgid of the receiver node on which this code is
      getting executed and sgid contains the GID of the sender.
      
      When resolving mac address of destination, you use arrived dgid as
      sgid and use sgid as dgid because sgid contains destinations GID whom to
      respond to.
      Signed-off-by: NGustavo A. R. Silva <garsilva@embeddedor.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      28b5b3a2
  5. 07 7月, 2017 2 次提交
  6. 03 7月, 2017 1 次提交
    • B
      RDMA/uverbs: Check port number supplied by user verbs cmds · 5ecce4c9
      Boris Pismenny 提交于
      The ib_uverbs_create_ah() ind ib_uverbs_modify_qp() calls receive
      the port number from user input as part of its attributes and assumes
      it is valid. Down on the stack, that parameter is used to access kernel
      data structures.  If the value is invalid, the kernel accesses memory
      it should not.  To prevent this, verify the port number before using it.
      
      BUG: KASAN: use-after-free in ib_uverbs_create_ah+0x6d5/0x7b0
      Read of size 4 at addr ffff880018d67ab8 by task syz-executor/313
      
      BUG: KASAN: slab-out-of-bounds in modify_qp.isra.4+0x19d0/0x1ef0
      Read of size 4 at addr ffff88006c40ec58 by task syz-executor/819
      
      Fixes: 67cdb40c ("[IB] uverbs: Implement more commands")
      Fixes: 189aba99 ("IB/uverbs: Extend modify_qp and support packet pacing")
      Cc: <stable@vger.kernel.org> # v2.6.14+
      Cc: <security@kernel.org>
      Cc: Yevgeny Kliteynik <kliteyn@mellanox.com>
      Cc: Tziporet Koren <tziporet@mellanox.com>
      Cc: Alex Polak <alexpo@mellanox.com>
      Signed-off-by: NBoris Pismenny <borisp@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leon@kernel.org>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      5ecce4c9
  7. 16 6月, 2017 1 次提交
    • J
      networking: make skb_put & friends return void pointers · 4df864c1
      Johannes Berg 提交于
      It seems like a historic accident that these return unsigned char *,
      and in many places that means casts are required, more often than not.
      
      Make these functions (skb_put, __skb_put and pskb_put) return void *
      and remove all the casts across the tree, adding a (u8 *) cast only
      where the unsigned char pointer was used directly, all done with the
      following spatch:
      
          @@
          expression SKB, LEN;
          typedef u8;
          identifier fn = { skb_put, __skb_put };
          @@
          - *(fn(SKB, LEN))
          + *(u8 *)fn(SKB, LEN)
      
          @@
          expression E, SKB, LEN;
          identifier fn = { skb_put, __skb_put };
          type T;
          @@
          - E = ((T *)(fn(SKB, LEN)))
          + E = fn(SKB, LEN)
      
      which actually doesn't cover pskb_put since there are only three
      users overall.
      
      A handful of stragglers were converted manually, notably a macro in
      drivers/isdn/i4l/isdn_bsdcomp.c and, oddly enough, one of the many
      instances in net/bluetooth/hci_sock.c. In the former file, I also
      had to fix one whitespace problem spatch introduced.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4df864c1
  8. 08 6月, 2017 1 次提交
    • R
      IB/addr: Fix setting source address in addr6_resolve() · 79e25959
      Roland Dreier 提交于
      Commit eea40b8f ("infiniband: call ipv6 route lookup via the stub
      interface") introduced a regression in address resolution when connecting
      to IPv6 destination addresses.  The old code called ip6_route_output(),
      while the new code calls ipv6_stub->ipv6_dst_lookup().  The two are almost
      the same, except that ipv6_dst_lookup() also calls ip6_route_get_saddr()
      if the source address is in6addr_any.
      
      This means that the test of ipv6_addr_any(&fl6.saddr) now never succeeds,
      and so we never copy the source address out.  This ends up causing
      rdma_resolve_addr() to fail, because without a resolved source address,
      cma_acquire_dev() will fail to find an RDMA device to use.  For me, this
      causes connecting to an NVMe over Fabrics target via RoCE / IPv6 to fail.
      
      Fix this by copying out fl6.saddr if ipv6_addr_any() is true for the original
      source address passed into addr6_resolve().  We can drop our call to
      ipv6_dev_get_saddr() because ipv6_dst_lookup() already does that work.
      
      Fixes: eea40b8f ("infiniband: call ipv6 route lookup via the stub interface")
      Cc: <stable@vger.kernel.org> # 3.12+
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      Acked-by: NPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      79e25959
  9. 02 6月, 2017 5 次提交
  10. 24 5月, 2017 3 次提交
    • 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
    • D
      selinux lsm IB/core: Implement LSM notification system · 8f408ab6
      Daniel Jurgens 提交于
      Add a generic notificaiton mechanism in the LSM. Interested consumers
      can register a callback with the LSM and security modules can produce
      events.
      
      Because access to Infiniband QPs are enforced in the setup phase of a
      connection security should be enforced again if the policy changes.
      Register infiniband devices for policy change notification and check all
      QPs on that device when the notification is received.
      
      Add a call to the notification mechanism from SELinux when the AVC
      cache changes or setenforce is cleared.
      Signed-off-by: NDaniel Jurgens <danielj@mellanox.com>
      Acked-by: NJames Morris <james.l.morris@oracle.com>
      Acked-by: NDoug Ledford <dledford@redhat.com>
      Signed-off-by: NPaul Moore <paul@paul-moore.com>
      8f408ab6
    • D
      IB/core: Enforce PKey security on QPs · d291f1a6
      Daniel Jurgens 提交于
      Add new LSM hooks to allocate and free security contexts and check for
      permission to access a PKey.
      
      Allocate and free a security context when creating and destroying a QP.
      This context is used for controlling access to PKeys.
      
      When a request is made to modify a QP that changes the port, PKey index,
      or alternate path, check that the QP has permission for the PKey in the
      PKey table index on the subnet prefix of the port. If the QP is shared
      make sure all handles to the QP also have access.
      
      Store which port and PKey index a QP is using. After the reset to init
      transition the user can modify the port, PKey index and alternate path
      independently. So port and PKey settings changes can be a merge of the
      previous settings and the new ones.
      
      In order to maintain access control if there are PKey table or subnet
      prefix change keep a list of all QPs are using each PKey index on
      each port. If a change occurs all QPs using that device and port must
      have access enforced for the new cache settings.
      
      These changes add a transaction to the QP modify process. Association
      with the old port and PKey index must be maintained if the modify fails,
      and must be removed if it succeeds. Association with the new port and
      PKey index must be established prior to the modify and removed if the
      modify fails.
      
      1. When a QP is modified to a particular Port, PKey index or alternate
         path insert that QP into the appropriate lists.
      
      2. Check permission to access the new settings.
      
      3. If step 2 grants access attempt to modify the QP.
      
      4a. If steps 2 and 3 succeed remove any prior associations.
      
      4b. If ether fails remove the new setting associations.
      
      If a PKey table or subnet prefix changes walk the list of QPs and
      check that they have permission. If not send the QP to the error state
      and raise a fatal error event. If it's a shared QP make sure all the
      QPs that share the real_qp have permission as well. If the QP that
      owns a security structure is denied access the security structure is
      marked as such and the QP is added to an error_list. Once the moving
      the QP to error is complete the security structure mark is cleared.
      
      Maintaining the lists correctly turns QP destroy into a transaction.
      The hardware driver for the device frees the ib_qp structure, so while
      the destroy is in progress the ib_qp pointer in the ib_qp_security
      struct is undefined. When the destroy process begins the ib_qp_security
      structure is marked as destroying. This prevents any action from being
      taken on the QP pointer. After the QP is destroyed successfully it
      could still listed on an error_list wait for it to be processed by that
      flow before cleaning up the structure.
      
      If the destroy fails the QPs port and PKey settings are reinserted into
      the appropriate lists, the destroying flag is cleared, and access control
      is enforced, in case there were any cache changes during the destroy
      flow.
      
      To keep the security changes isolated a new file is used to hold security
      related functionality.
      Signed-off-by: NDaniel Jurgens <danielj@mellanox.com>
      Acked-by: NDoug Ledford <dledford@redhat.com>
      [PM: merge fixup in ib_verbs.h and uverbs_cmd.c]
      Signed-off-by: NPaul Moore <paul@paul-moore.com>
      d291f1a6
  11. 23 5月, 2017 1 次提交
  12. 02 5月, 2017 10 次提交