[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <a3f851fb-e148-d386-e9dd-29e7d89c93fa@mellanox.com>
Date: Fri, 22 Nov 2019 07:21:22 +0000
From: Parav Pandit <parav@...lanox.com>
To: David Miller <davem@...emloft.net>,
"dan.carpenter@...cle.com" <dan.carpenter@...cle.com>
CC: Jiri Pirko <jiri@...lanox.com>,
"dsahern@...il.com" <dsahern@...il.com>,
Ido Schimmel <idosch@...lanox.com>,
Petr Machata <petrm@...lanox.com>,
"jakub.kicinski@...ronome.com" <jakub.kicinski@...ronome.com>,
"nikolay@...ulusnetworks.com" <nikolay@...ulusnetworks.com>,
"roopa@...ulusnetworks.com" <roopa@...ulusnetworks.com>,
"johannes.berg@...el.com" <johannes.berg@...el.com>,
"mkubecek@...e.cz" <mkubecek@...e.cz>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
"kernel-janitors@...r.kernel.org" <kernel-janitors@...r.kernel.org>
Subject: Re: [PATCH net] net: rtnetlink: prevent underflows in do_setvfinfo()
On 11/21/2019 4:44 PM, David Miller wrote:
> From: Dan Carpenter <dan.carpenter@...cle.com>
> Date: Wed, 20 Nov 2019 15:34:38 +0300
>
>> The "ivm->vf" variable is a u32, but the problem is that a number of
>> drivers cast it to an int and then forget to check for negatives. An
>> example of this is in the cxgb4 driver.
>>
>> drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
>> 2890 static int cxgb4_mgmt_get_vf_config(struct net_device *dev,
>> 2891 int vf, struct ifla_vf_info *ivi)
>> ^^^^^^
>> 2892 {
>> 2893 struct port_info *pi = netdev_priv(dev);
>> 2894 struct adapter *adap = pi->adapter;
>> 2895 struct vf_info *vfinfo;
>> 2896
>> 2897 if (vf >= adap->num_vfs)
>> ^^^^^^^^^^^^^^^^^^^
>> 2898 return -EINVAL;
>> 2899 vfinfo = &adap->vfinfo[vf];
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>> There are 48 functions affected.
> ...
>> Signed-off-by: Dan Carpenter <dan.carpenter@...cle.com>
> I'm going to apply this and queue it up for -stable.
>
> The u32 conversion should happen in next.
okay.
When Dan reported, I reviewed and wrote the patch for u32, and some more
code consolidation with it.
But hit the block with u32 leading to overflow to 0 which modifies the
first VF incorrectly.
Checking num_vfs of pci dev, without device_lock() is equally buggy as
it stands today.
Creating a lock in each vendor driver(s) doesn't make sense.
Haven't had chance yet after that.
Let me know if someone has a suggestion that I should incorporate.
Powered by blists - more mailing lists