Re: [PATCH v2] scsi: lpfc: Add rport validation in lpfc_dev_loss_tmo_callbk

[Ewan Milne]

On Mon, Jun 29, 2026 at 3:01 PM Vaibhav Nagare <nagarevaibhav@xxxxxxxxx> wrote:
>
>   Fix a kernel NULL pointer dereference in lpfc_dev_loss_tmo_callbk()
>   when ndlp->vport is NULL during FC remote port deletion.
>
>   The crash occurs during fc_rport_final_delete() when the vport has
>   already been cleared on the ndlp structure, but the dev_loss_tmo
>   callback is still invoked.
>
>   The driver already has lpfc_rport_invalid() which validates rport,
>   rdata, ndlp, and vport. The function lpfc_terminate_rport_io() uses
>   this validation, but lpfc_dev_loss_tmo_callbk() does not, leading
>   to a NULL pointer dereference when accessing vport->phba.
>

Yeah but this doesn't really fix the problem.  It may avoid a crash in
this particular place in lpfc_dev_loss_tmo_callbk() but the cause of the
null ndlp->vport pointer is that the lpfc_nodelist object has already
been freed due to an incorrect refcount.  If we return prematurely
the driver is not cleaning up the rport state properly.

Unfortunately it can be difficult to pinpoint the cause of the prematurely
decremented refcount and we have been chasing these problems for
years.

Prior to c6adba150191 ("scsi: lpfc: Rework remote port lock handling")
lpfc_nlp_release() did not set ndlp->vport = NULL, among other things
and so the driver typically did not crash but operated with a use-after-free
and probably did not behave correctly,

-Ewan