linux-kernel - Re: [PATCH -next] scsi: libfc: Fix potential NULL pointer dereference

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: <33f93c39-3dd5-ef95-0fc2-6fc40f6b3d4b@suse.de>
Date:   Wed, 27 Feb 2019 13:51:06 +0100
From:   Hannes Reinecke <hare@...e.de>
To:     YueHaibing <yuehaibing@...wei.com>, jejb@...ux.ibm.com,
        martin.petersen@...cle.com
Cc:     linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org
Subject: Re: [PATCH -next] scsi: libfc: Fix potential NULL pointer dereference

On 2/27/19 7:09 AM, YueHaibing wrote:
> 
> Friendly ping:
> 
> Who can review or take this, please?
> 
> Thanks
> 
> On 2019/1/30 18:11, YueHaibing wrote:
>> There is a potential NULL pointer dereference in case
>> fc_rport_create() fails and returns NULL.
>>
>> Fixes: 2580064b5ec6 ("scsi: libfc: Replace ->rport_create callback with function call")
>> Signed-off-by: YueHaibing <yuehaibing@...wei.com>
>> ---
>>   drivers/scsi/libfc/fc_lport.c | 4 ++++
>>   1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/scsi/libfc/fc_lport.c b/drivers/scsi/libfc/fc_lport.c
>> index ff943f4..e2a3551 100644
>> --- a/drivers/scsi/libfc/fc_lport.c
>> +++ b/drivers/scsi/libfc/fc_lport.c
>> @@ -250,6 +250,10 @@ static void fc_lport_ptp_setup(struct fc_lport *lport,
>>   	}
>>   	mutex_lock(&lport->disc.disc_mutex);
>>   	lport->ptp_rdata = fc_rport_create(lport, remote_fid);
>> +	if (!lport->ptp_rdata) {
>> +		mutex_unlock(&lport->disc.disc_mutex);
>> +		return;
>> +	}
>>   	kref_get(&lport->ptp_rdata->kref);
>>   	lport->ptp_rdata->ids.port_name = remote_wwpn;
>>   	lport->ptp_rdata->ids.node_name = remote_wwnn;
>>
> 
I don't think this is correct.
While it's true that fc_rport_create() might fail, fc_lport_ptp_setup() 
will still assumed to have worked by the caller.
So we should rather return an error code here from fc_lport_ptp_setup() 
and ensure it's handled properly in the caller, too.

Cheers,

Hannes