Thread (3 messages) 3 messages, 3 authors, 2021-12-01

Re: [PATCH] scsi: libfc: Fix a NULL pointer dereference in fc_lport_ptp_setup()

From: James Bottomley <hidden>
Date: 2021-11-30 18:13:58
Also in: lkml

On Wed, 2021-12-01 at 01:10 +0800, Zhou Qingyang wrote:
quoted hunk ↗ jump to hunk
In fc_lport_ptp_setup(), fc_rport_create() is assigned to
lport->ptp_rdata and there is a dereference of in
fc_lport_ptp_setup(),
which could lead to a NULL pointer dereference on failure of
fc_rport_create().

Fix this bug by adding a check of fc_rport_create().

This bug was found by a static analyzer. The analysis employs
differential checking to identify inconsistent security operations
(e.g., checks or kfrees) between two code paths and confirms that the
inconsistent operations are not recovered in the current function or
the callers, so they constitute bugs.

Note that, as a bug found by static analysis, it can be a false
positive or hard to trigger. Multiple researchers have cross-reviewed
the bug.

Builds with CONFIG_LIBFC=m show no new warnings,
and our static analyzer no longer warns about this code.

Fixes: 2580064b5ec6 ("scsi: libfc: Replace ->rport_create callback
with function call")
Signed-off-by: Zhou Qingyang <redacted>
---
 drivers/scsi/libfc/fc_lport.c | 7 +++++++
 1 file changed, 7 insertions(+)
diff --git a/drivers/scsi/libfc/fc_lport.c
b/drivers/scsi/libfc/fc_lport.c
index 19cd4a95d354..5cd716afb711 100644
--- a/drivers/scsi/libfc/fc_lport.c
+++ b/drivers/scsi/libfc/fc_lport.c
@@ -241,6 +241,13 @@ 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);
+		printk(KERN_WARNING "libfc: Failed to allocate for the
port (%6.6x)\n",
+				remote_fid);
+		return;
+	}
+
This really doesn't look like a good idea.  Most GFP_KERNEL allocations
aren't going to fail unless the kernel is about to wedge anyway under
reclaim pressure.  fc_lport_ptp_setup is assumed to succeed if it
returns, there's no error handling, so the kernel would now continue in
an unexpected state if it recovers from the reclaim issue.

The kmalloc failure will have printed a message anyway and the oops
trace from the NULL deref would identify the location if it's relevant
and likely kill the iscsi daemon, so setting up a time bomb for someone
else really doesn't look to be improving the code.

James

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help