* [PATCH -next] scsi: libfc: Fix potential NULL pointer dereference
@ 2019-01-30 10:11 YueHaibing
2019-02-27 6:09 ` YueHaibing
0 siblings, 1 reply; 5+ messages in thread
From: YueHaibing @ 2019-01-30 10:11 UTC (permalink / raw)
To: hare, jejb, martin.petersen; +Cc: linux-kernel, linux-scsi, YueHaibing
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@huawei.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;
--
2.7.0
^ permalink raw reply related [flat|nested] 5+ messages in thread* Re: [PATCH -next] scsi: libfc: Fix potential NULL pointer dereference
2019-01-30 10:11 [PATCH -next] scsi: libfc: Fix potential NULL pointer dereference YueHaibing
@ 2019-02-27 6:09 ` YueHaibing
2019-02-27 12:51 ` Hannes Reinecke
2019-03-07 12:11 ` Hannes Reinecke
0 siblings, 2 replies; 5+ messages in thread
From: YueHaibing @ 2019-02-27 6:09 UTC (permalink / raw)
To: hare, jejb, martin.petersen; +Cc: linux-kernel, linux-scsi
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@huawei.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;
>
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [PATCH -next] scsi: libfc: Fix potential NULL pointer dereference
2019-02-27 6:09 ` YueHaibing
@ 2019-02-27 12:51 ` Hannes Reinecke
2019-03-07 12:11 ` Hannes Reinecke
1 sibling, 0 replies; 5+ messages in thread
From: Hannes Reinecke @ 2019-02-27 12:51 UTC (permalink / raw)
To: YueHaibing, jejb, martin.petersen; +Cc: linux-kernel, linux-scsi
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@huawei.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
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [PATCH -next] scsi: libfc: Fix potential NULL pointer dereference
2019-02-27 6:09 ` YueHaibing
2019-02-27 12:51 ` Hannes Reinecke
@ 2019-03-07 12:11 ` Hannes Reinecke
2019-03-14 11:06 ` Martin K. Petersen
1 sibling, 1 reply; 5+ messages in thread
From: Hannes Reinecke @ 2019-03-07 12:11 UTC (permalink / raw)
To: YueHaibing, jejb, martin.petersen; +Cc: linux-kernel, linux-scsi
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@huawei.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;
>>
>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Cheers,
Hannes
--
Dr. Hannes Reinecke Teamlead Storage & Networking
hare@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [PATCH -next] scsi: libfc: Fix potential NULL pointer dereference
2019-03-07 12:11 ` Hannes Reinecke
@ 2019-03-14 11:06 ` Martin K. Petersen
0 siblings, 0 replies; 5+ messages in thread
From: Martin K. Petersen @ 2019-03-14 11:06 UTC (permalink / raw)
To: Hannes Reinecke
Cc: YueHaibing, jejb, martin.petersen, linux-kernel, linux-scsi
Hi Hannes,
>>> There is a potential NULL pointer dereference in case
>>> fc_rport_create() fails and returns NULL.
>>> 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;
>>>
> Reviewed-by: Hannes Reinecke <hare@suse.com>
A bit confused. You had originally replied that the patch was not
correct so I closed it in patchwork. And now there's a Reviewed-by:
without any explanation as to why you have changed your mind.
Please clarify, thanks!
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2019-03-14 11:08 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-01-30 10:11 [PATCH -next] scsi: libfc: Fix potential NULL pointer dereference YueHaibing
2019-02-27 6:09 ` YueHaibing
2019-02-27 12:51 ` Hannes Reinecke
2019-03-07 12:11 ` Hannes Reinecke
2019-03-14 11:06 ` Martin K. Petersen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox