netdev - Re: [PATCH] qed/qed_sriov: avoid null-ptr-deref

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: <43c68803-89c4-431f-b016-62a6ad68313f@huaweicloud.com>
Date: Tue, 29 Oct 2024 09:42:11 +0800
From: Chen Ridong <chenridong@...weicloud.com>
To: Alexander Lobakin <aleksander.lobakin@...el.com>,
 Chen Ridong <chenridong@...weicloud.com>
Cc: manishc@...vell.com, andrew+netdev@...n.ch, davem@...emloft.net,
 edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
 netdev@...r.kernel.org, wangweiyang2@...wei.com
Subject: Re: [PATCH] qed/qed_sriov: avoid null-ptr-deref



On 2024/10/25 23:28, Alexander Lobakin wrote:
> From: Chen Ridong <chenridong@...weicloud.com>
> Date: Fri, 25 Oct 2024 09:31:35 +0000
> 
>> [PATCH] qed/qed_sriov: avoid null-ptr-deref
> 
> Use the correct tree prefix, [PATCH net] in your case.
> 

Thanks, will update

>> From: Chen Ridong <chenridong@...wei.com>
> 
> Why do you commit from @huawei.com, but send from @huaweicloud.com?
> 
The @huawei.com is the email I am actually using. But if I use it to
send email, my patches may not appear in maintainers's inbox list. This
won't be happened when I use 'huaweicloud.com' to send emails. So I am
using 'huaweicloud.com' to communicate with community. However, I would
like to maintain the same author identity.

>>
>> The qed_iov_get_public_vf_info may return NULL, which may lead to
>> null-ptr-deref. To avoid possible null-ptr-deref, check vf_info
> 
> Do you have a repro for this or it's purely hypothetical?
> 

I read the code and found that calling qed_iov_get_public_vf_info
without checking whether the 'vfid' is valid  may result in a null
pointer, which may lead to a null pointer dereference.

>> before accessing its member.
>>
> 
> Here you should have a "Fixes:" tag if you believe this is a fix.
> 
>> Signed-off-by: Chen Ridong <chenridong@...wei.com>
>> ---
>>  drivers/net/ethernet/qlogic/qed/qed_sriov.c | 5 +++++
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/drivers/net/ethernet/qlogic/qed/qed_sriov.c b/drivers/net/ethernet/qlogic/qed/qed_sriov.c
>> index fa167b1aa019..30da9865496d 100644
>> --- a/drivers/net/ethernet/qlogic/qed/qed_sriov.c
>> +++ b/drivers/net/ethernet/qlogic/qed/qed_sriov.c
>> @@ -2997,6 +2997,8 @@ static int qed_iov_pre_update_vport(struct qed_hwfn *hwfn,
>>  		return 0;
>>  
>>  	vf_info = qed_iov_get_public_vf_info(hwfn, vfid, true);
>> +	if (!vf_info)
>> +		return 0;
> 
> 0 or error code?

It should return error code after I read the code again.
Thank you very much.

> 
>>  
>>  	if (flags->update_rx_mode_config) {
>>  		vf_info->rx_accept_mode = flags->rx_accept_filter;
> 
> Thanks,
> Olek
> 

Best regards,
Ridong