On Tue, 2018-04-24 at 20:13 +0300, Leon Romanovsky wrote:
> From: Parav Pandit <parav@xxxxxxxxxxxx>
>
> There are few issues with validation of netdevice and listen id lookup
> for IB (IPoIB) while processing incoming CM request as below.
>
> 1. While performing lookup of bind_list in cma_ps_find(), net namespace
> of the netdevice can get deleted in cma_exit_net(), resulting in use
> after free access of idr and/or net namespace structures.
> This lookup occurs from the workqueue context (and not userspace
> context where net namespace is always valid).
>
> CPU0 CPU1
> ==== ====
>
> bind_list = cma_ps_find();
> move netdevice to new namespace
> delete net namespace
> cma_exit_net()
> idr_destroy(idr);
>
> [..]
> cma_find_listener(bind_list, ..);
>
> 2. While netdevice is validated for IP address in given net namespace,
> netdevice's net namespace and/or ifindex can change in
> cma_get_net_dev() and cma_match_net_dev().
>
> Above issues are overcome by using rcu lock along with netdevice
> UP/DOWN state as described below.
> When a net namespace is getting deleted, netdevice is closed and
> shutdown before moving it back to init_net namespace.
> change_net_namespace() synchronizes with any existing use of netdevice
> before changing the netdev properties such as net or ifindex.
> Once netdevice IFF_UP flags is cleared, such fields are not guaranteed
> to be valid.
> Therefore, rcu lock along with netdevice state check ensures that,
> while route lookup and cm_id lookup is in progress, netdevice of
> interest won't migrate to any other net namespace.
> This ensures that associated net namespace of netdevice won't get
> deleted while rcu lock is held for netdevice which is in IFF_UP state.
>
> Fixes: fa20105e09e9 ("IB/cma: Add support for network namespaces")
> Fixes: 4be74b42a6d0 ("IB/cma: Separate port allocation to network namespaces")
> Fixes: f887f2ac87c2 ("IB/cma: Validate routing of incoming requests")
> Signed-off-by: Parav Pandit <parav@xxxxxxxxxxxx>
> Signed-off-by: Leon Romanovsky <leonro@xxxxxxxxxxxx>
Thanks, applied.
--
Doug Ledford <dledford@xxxxxxxxxx>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDDAttachment:
signature.asc
Description: This is a digitally signed message part
