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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx>
---
  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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]

  Powered by Linux