netdev - Re: net/mlx5: Maintain separate page trees for ECPF and PF functions

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>] [day] [month] [year] [list]

Message-ID: <86dab3fb-0581-34c3-7b75-9ee809dce66a@nvidia.com>
Date:   Fri, 29 Jan 2021 22:06:28 +0200
From:   Eran Ben Elisha <eranbe@...dia.com>
To:     Colin Ian King <colin.king@...onical.com>,
        Daniel Jurgens <danielj@...dia.com>
CC:     Saeed Mahameed <saeedm@...dia.com>,
        Leon Romanovsky <leon@...nel.org>,
        Moshe Shemesh <moshe@...lanox.com>,
        Eran Ben Elisha <eranbe@...lanox.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        <linux-rdma@...r.kernel.org>
Subject: Re: net/mlx5: Maintain separate page trees for ECPF and PF functions



On 1/29/2021 2:18 PM, Colin Ian King wrote:
> Hi,
> 
> Static analysis with Coverity has detected an issue with the following
> commit:
> 
> commit 0aa128475d33d2d0095947eeab6b3e4d22dbd578
> Author: Daniel Jurgens <danielj@...dia.com>
> Date:   Fri Jan 22 23:13:53 2021 +0200
> 
>      net/mlx5: Maintain separate page trees for ECPF and PF functions
> 
> The analysis is as follows:
> 
>   77 static u32 get_function(u16 func_id, bool ec_function)
>   78 {
> 
> Operands don't affect result (CONSTANT_EXPRESSION_RESULT)
> result_independent_of_operands: func_id & (ec_function << 16) is always
> 0 regardless of the values of its operands. This occurs as a return value.
> 
>   79        return func_id & (ec_function << 16);
>   80 }
> 
> 
> boolean ec_function is shifted 16 places to the left, so the result is
> going to be 0x10000 or 0x00000. Bit-wise and'ing this with the 16 bit
> unsigned int func_id will always result in a zero.  Not sure what the
> intention is, so I can't fix it.
> 
> Either the & operator should be |,  or func_id should be wider than a u16

Hi, thanks for the report.
The u32 return value was supposed to be a concatenation of 16-bit 
func_id and ec flag.
Hence, indeed there is a bug here.

it should be
return (u32)func_id | (ec_function << 16);

Please update if you want to post this fix patch or prefer Me/Daniel to 
take it.

Eran
> 
> Colin
>