Re: [PATCH linux-next 1/4] infiniband/ipoib: fix possible NULL pointer dereference in ipoib_get_iflink

From: Erez Shitrit
Date: Thu Apr 16 2015 - 07:28:15 EST


On Wed, Apr 15, 2015 at 7:06 PM, Jason Gunthorpe
<jgunthorpe@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Wed, Apr 15, 2015 at 09:17:14AM +0300, Erez Shitrit wrote:
>> >>+ /* parent interface */
>> >>+ if (!test_bit(IPOIB_FLAG_SUBINTERFACE, &priv->flags))
>> >>+ return dev->ifindex;
>> >>+
>> >>+ /* child/vlan interface */
>> >>+ if (!priv->parent)
>> >>+ return -1;
>
>> >Like was said for other drivers, I can't see how parent can be null
>> >while IPOIB_FLAG_SUBINTERFACE is set. Drop the last if.
>
>> It can, at least for ipoib child interface (AKA "vlan"), you can't
>> control the call for that ndo and it can be called before the parent
>> was set.
>
> If the ndo can be called before the netdev private structures are fully
> prepared then we have another bug, and returning -1 or 0 is not the right
> answer anyhow.
>
> For safety, fold this into your patch.

OK, will do that.

>
> diff --git a/drivers/infiniband/ulp/ipoib/ipoib_vlan.c b/drivers/infiniband/ulp/ipoib/ipoib_vlan.c
> index 9fad7b5ac8b9..e62b007adf5d 100644
> --- a/drivers/infiniband/ulp/ipoib/ipoib_vlan.c
> +++ b/drivers/infiniband/ulp/ipoib/ipoib_vlan.c
> @@ -58,6 +58,7 @@ int __ipoib_vlan_add(struct ipoib_dev_priv *ppriv, struct ipoib_dev_priv *priv,
> /* MTU will be reset when mcast join happens */
> priv->dev->mtu = IPOIB_UD_MTU(priv->max_ib_mtu);
> priv->mcast_mtu = priv->admin_mtu = priv->dev->mtu;
> + priv->parent = ppriv->dev;
> set_bit(IPOIB_FLAG_SUBINTERFACE, &priv->flags);
>
> result = ipoib_set_dev_features(priv, ppriv->ca);
> @@ -84,8 +85,6 @@ int __ipoib_vlan_add(struct ipoib_dev_priv *ppriv, struct ipoib_dev_priv *priv,
> goto register_failed;
> }
>
> - priv->parent = ppriv->dev;
> -
> ipoib_create_debug_files(priv->dev);
>
> /* RTNL childs don't need proprietary sysfs entries */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/