linux-kernel - Re: [PATCH V2] net/mlx5e: fix potential null dereference in mlx5e_tc_nic_create_miss

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8948a9d5-0b0d-4df7-9958-dc6f8f300e2f@nvidia.com>
Date: Tue, 8 Apr 2025 18:16:31 +0300
From: Mark Bloch <mbloch@...dia.com>
To: Charles Han <hanchunchao@...pur.com>,
 Tariq Toukan <ttoukan.linux@...il.com>
Cc: saeedm@...dia.com, tariqt@...dia.com, leon@...nel.org,
 andrew+netdev@...n.ch, davem@...emloft.net, edumazet@...gle.com,
 kuba@...nel.org, pabeni@...hat.com, lariel@...dia.com, paulb@...dia.com,
 maord@...dia.com, netdev@...r.kernel.org, linux-rdma@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH V2] net/mlx5e: fix potential null dereference in
 mlx5e_tc_nic_create_miss_table



On 08/04/2025 10:06, Charles Han wrote:
> On Mon, Apr 07, 2025 at 12:29:22PM +0300, Tariq Toukan wrote:
>>
>>
>> On 07/04/2025 10:20, Charles Han wrote:
>>> mlx5_get_flow_namespace() may return a NULL pointer, dereferencing it
>>> without NULL check may lead to NULL dereference.
>>> Add a NULL check for ns.
>>>
>>> Fixes: 66cb64e292d2 ("net/mlx5e: TC NIC mode, fix tc chains miss table")
>>> Signed-off-by: Charles Han <hanchunchao@...pur.com>
>>> ---
>>>   drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 4 ++++
>>>   1 file changed, 4 insertions(+)
>>>
>>> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
>>> index 9ba99609999f..c2f23ac95c3d 100644
>>> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
>>> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
>>> @@ -5216,6 +5216,10 @@ static int mlx5e_tc_nic_create_miss_table(struct mlx5e_priv *priv)
>>>   	ft_attr.level = MLX5E_TC_MISS_LEVEL;
>>>   	ft_attr.prio = 0;
>>>   	ns = mlx5_get_flow_namespace(priv->mdev, MLX5_FLOW_NAMESPACE_KERNEL);
>>> +	if (!ns) {
>>> +		netdev_err(priv->mdev, "Failed to get flow namespace\n");
>>> +		return -EOPNOTSUPP;
>>> +	}
>>>   	*ft = mlx5_create_auto_grouped_flow_table(ns, &ft_attr);
>>>   	if (IS_ERR(*ft)) {
>>
>> Same question here, did it fail for you, or just saw it while reading the
>> code?
> I just saw it while reading the code.
> I've been working on code vulnerability scanning recently.
> 

I don't believe this scenario can actually occur.
The function mlx5e_tc_nic_init() is called from mlx5e_init_nic_rx(),
and before that, we invoke mlx5e_create_flow_steering().

In mlx5e_create_flow_steering(), the first operation is:

<snip>
int mlx5e_create_flow_steering(struct mlx5e_flow_steering *fs,
                               struct mlx5e_rx_res *rx_res,
                               const struct mlx5e_profile *profile,
                               struct net_device *netdev)
{
        struct mlx5_flow_namespace *ns = mlx5_get_flow_namespace(fs->mdev,
                                                                 MLX5_FLOW_NAMESPACE_KERNEL);
        int err;

        if (!ns)
                return -EOPNOTSUPP;
</snip>

Note that MLX5_FLOW_NAMESPACE_KERNEL is allocated and initialized at
driver startup (as most/all namespaces), and it does not
change dynamically.

If mlx5e_create_flow_steering() fails, it indicates that
something fundamental isn't functioning correctly, and we
never proceed to the more advanced functionality (like tc).

Mark