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

[James Bottomley]

On Wed, 2021-12-01 at 01:10 +0800, Zhou Qingyang wrote:
> 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 <zhou1615@xxxxxxx>
> ---
>  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