[PATCH v3 0/3] scsi: lpfc: Fix multiple memory leaks in error paths

[PATCH v3 0/3] scsi: lpfc: Fix multiple memory leaks in error paths

[Zilin Guan]

This series fixes three independent memory leaks in the lpfc driver.
All of them occur in error handling paths where allocated memory
was not properly freed before returning.

These issues were identified during static analysis.

Signed-off-by: Zilin Guan <zilin@seu.edu.cn>

Changes in v3:
- Patch 1: Remove unnecessary braces for single-line if statement.
- Patch 2: No changes.
- Patch 3: No changes.

Changes in v2:
- Patch 1: Refactor error handling to use a goto label for cleanup.
- Patch 2: No changes.
- Patch 3: No changes.

Zilin Guan (3):
  scsi: lpfc: Fix memory leak in lpfc_config_port_post()
  scsi: lpfc: Fix memory leak in lpfc_sli4_driver_resource_setup()
  scsi: lpfc: Fix memory leak in lpfc_cmpl_plogi_plogi_issue()

 drivers/scsi/lpfc/lpfc_init.c      | 25 +++++++++++++------------
 drivers/scsi/lpfc/lpfc_nportdisc.c |  4 +++-
 2 files changed, 16 insertions(+), 13 deletions(-)

-- 
2.34.1

[PATCH v3 1/3] scsi: lpfc: Fix memory leak in lpfc_config_port_post()

[Zilin Guan]

In lpfc_config_port_post(), pmb is allocated via mempool_alloc() but
is not freed when lpfc_readl() fails.

Instead of simply adding the missing free, refactor the error handling
to use a goto label. This unifies the cleanup logic and ensures pmb is
freed in all error paths.

Fixes: 9940b97bb30d ("[SCSI] lpfc 8.3.22: Add support for PCI Adapter Failure")
Suggested-by: Markus Elfring <Markus.Elfring@web.de>
Co-developed-by: Jianhao Xu <jianhao.xu@seu.edu.cn>
Signed-off-by: Jianhao Xu <jianhao.xu@seu.edu.cn>
Signed-off-by: Zilin Guan <zilin@seu.edu.cn>
---
Changes in v3:
- Remove unnecessary braces for single-line if statement.

Changes in v2:
- Refactor error handling to use a goto label for cleanup.

 drivers/scsi/lpfc/lpfc_init.c | 23 +++++++++++------------
 1 file changed, 11 insertions(+), 12 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c
index b1460b16dd91..c520d314b131 100644
--- a/drivers/scsi/lpfc/lpfc_init.c
+++ b/drivers/scsi/lpfc/lpfc_init.c
@@ -511,8 +511,7 @@ lpfc_config_port_post(struct lpfc_hba *phba)
 				"READ_CONFIG, mbxStatus x%x\n",
 				mb->mbxCommand, mb->mbxStatus);
 		phba->link_state = LPFC_HBA_ERROR;
-		mempool_free( pmb, phba->mbox_mem_pool);
-		return -EIO;
+		goto out_free;
 	}
 
 	/* Check if the port is disabled */
@@ -549,10 +548,9 @@ lpfc_config_port_post(struct lpfc_hba *phba)
 	 */
 	if (phba->intr_type == MSIX) {
 		rc = lpfc_config_msi(phba, pmb);
-		if (rc) {
-			mempool_free(pmb, phba->mbox_mem_pool);
-			return -EIO;
-		}
+		if (rc)
+			goto out_free;
+
 		rc = lpfc_sli_issue_mbox(phba, pmb, MBX_POLL);
 		if (rc != MBX_SUCCESS) {
 			lpfc_printf_log(phba, KERN_ERR, LOG_TRACE_EVENT,
@@ -560,8 +558,7 @@ lpfc_config_port_post(struct lpfc_hba *phba)
 					"failed, mbxCmd x%x, mbxStatus x%x\n",
 					pmb->u.mb.mbxCommand,
 					pmb->u.mb.mbxStatus);
-			mempool_free(pmb, phba->mbox_mem_pool);
-			return -EIO;
+			goto out_free;
 		}
 	}
 
@@ -572,7 +569,7 @@ lpfc_config_port_post(struct lpfc_hba *phba)
 	/* Enable appropriate host interrupts */
 	if (lpfc_readl(phba->HCregaddr, &status)) {
 		spin_unlock_irq(&phba->hbalock);
-		return -EIO;
+		goto out_free;
 	}
 	status |= HC_MBINT_ENA | HC_ERINT_ENA | HC_LAINT_ENA;
 	if (psli->num_rings > 0)
@@ -616,9 +613,7 @@ lpfc_config_port_post(struct lpfc_hba *phba)
 			lpfc_printf_log(phba, KERN_ERR, LOG_TRACE_EVENT,
 					"2599 Adapter failed to issue DOWN_LINK"
 					" mbox command rc 0x%x\n", rc);
-
-			mempool_free(pmb, phba->mbox_mem_pool);
-			return -EIO;
+			goto out_free;
 		}
 	} else if (phba->cfg_suppress_link_up == LPFC_INITIALIZE_LINK) {
 		mempool_free(pmb, phba->mbox_mem_pool);
@@ -666,6 +661,10 @@ lpfc_config_port_post(struct lpfc_hba *phba)
 	}
 
 	return 0;
+
+out_free:
+	mempool_free(pmb, phba->mbox_mem_pool);
+	return -EIO;
 }
 
 /**
-- 
2.34.1

[PATCH v3 2/3] scsi: lpfc: Fix memory leak in lpfc_sli4_driver_resource_setup()

[Zilin Guan]

In lpfc_sli4_driver_resource_setup(), mboxq is allocated via
mempool_alloc() but is not freed when the allocation of
phba->lpfc_sg_dma_buf_pool or phba->lpfc_cmd_rsp_buf_pool fails.

Fix this by adding mempool_free() in the error paths.

Fixes: d79c9e9d4b3d ("scsi: lpfc: Support dynamic unbounded SGL lists on G7 hardware.")
Co-developed-by: Jianhao Xu <jianhao.xu@seu.edu.cn>
Signed-off-by: Jianhao Xu <jianhao.xu@seu.edu.cn>
Signed-off-by: Zilin Guan <zilin@seu.edu.cn>
---
 drivers/scsi/lpfc/lpfc_init.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c
index c520d314b131..6f4d9c618829 100644
--- a/drivers/scsi/lpfc/lpfc_init.c
+++ b/drivers/scsi/lpfc/lpfc_init.c
@@ -8295,6 +8295,7 @@ lpfc_sli4_driver_resource_setup(struct lpfc_hba *phba)
 					i, 0);
 	if (!phba->lpfc_sg_dma_buf_pool) {
 		rc = -ENOMEM;
+		mempool_free(mboxq, phba->mbox_mem_pool);
 		goto out_free_bsmbx;
 	}
 
@@ -8306,6 +8307,7 @@ lpfc_sli4_driver_resource_setup(struct lpfc_hba *phba)
 					i, 0);
 	if (!phba->lpfc_cmd_rsp_buf_pool) {
 		rc = -ENOMEM;
+		mempool_free(mboxq, phba->mbox_mem_pool);
 		goto out_free_sg_dma_buf;
 	}
 
-- 
2.34.1

[PATCH v3 3/3] scsi: lpfc: Fix memory leak in lpfc_cmpl_plogi_plogi_issue()

[Zilin Guan]

In lpfc_cmpl_plogi_plogi_issue(), mbox is allocated via
mempool_alloc() and initialized. However, if lpfc_nlp_get() fails,
the mbox and its resources are not freed.

Fix this by using lpfc_mbox_rsrc_cleanup() to free the mailbox and
its associated resources.

Fixes: 4430f7fd09ec ("scsi: lpfc: Rework locations of ndlp reference taking")
Co-developed-by: Jianhao Xu <jianhao.xu@seu.edu.cn>
Signed-off-by: Jianhao Xu <jianhao.xu@seu.edu.cn>
Signed-off-by: Zilin Guan <zilin@seu.edu.cn>
---
 drivers/scsi/lpfc/lpfc_nportdisc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/lpfc/lpfc_nportdisc.c b/drivers/scsi/lpfc/lpfc_nportdisc.c
index 8240d59f4120..e81640223276 100644
--- a/drivers/scsi/lpfc/lpfc_nportdisc.c
+++ b/drivers/scsi/lpfc/lpfc_nportdisc.c
@@ -1505,8 +1505,10 @@ lpfc_cmpl_plogi_plogi_issue(struct lpfc_vport *vport,
 		}
 
 		mbox->ctx_ndlp = lpfc_nlp_get(ndlp);
-		if (!mbox->ctx_ndlp)
+		if (!mbox->ctx_ndlp) {
+			lpfc_mbox_rsrc_cleanup(phba, mbox, MBOX_THD_UNLOCKED);
 			goto out;
+		}
 
 		mbox->vport = vport;
 		if (lpfc_sli_issue_mbox(phba, mbox, MBX_NOWAIT)
-- 
2.34.1

Re: [v3 0/3] scsi: lpfc: Fix multiple memory leaks in error paths

[Markus Elfring]

…
> These issues were identified during static analysis.

How do you think about to share further information according to
your source code analysis approach?

Regards,
Markus

Re: [v3 0/3] scsi: lpfc: Fix multiple memory leaks in error paths

[Zilin Guan]

On Wed, Dec 31, 2025 at 05:33:32PM +0100, Markus Elfring wrote:
> …
> > These issues were identified during static analysis.
> 
> How do you think about to share further information according to
> your source code analysis approach?
> 
> Regards,
> Markus

Hi Markus,

Thank you for your inquiry.

I believe the commit messages in each individual patch within this series 
already provide a clear and specific description of the identified issues 
and the analysis of the failure paths.

Best regards,
Zilin Guan

Re: [v3 0/3] scsi: lpfc: Fix multiple memory leaks in error paths

[Markus Elfring]

>> …
>>> These issues were identified during static analysis.
>>
>> How do you think about to share further information according to
>> your source code analysis approach?
…
> Thank you for your inquiry.
> 
> I believe the commit messages in each individual patch within this series 
> already provide a clear and specific description of the identified issues 
> and the analysis of the failure paths.

You presented interesting development ideas.
Will any related concerns become relevant here?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/researcher-guidelines.rst?h=v6.19-rc3#n5

Did your analysis approach get a corresponding name?

Regards,
Markus

Re: [v3 0/3] scsi: lpfc: Fix multiple memory leaks in error paths

[Zilin Guan]

On Sat, Jan 03, 2026 at 02:30:36PM +0100, Markus Elfring wrote:
> You presented interesting development ideas.
> Will any related concerns become relevant here?
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/researcher-guidelines.rst?h=v6.19-rc3#n5
> 
> Did your analysis approach get a corresponding name?
> 
> Regards,
> Markus

We are aware of these ethics requirements and strictly respect them.
For example, we responsibly disclose our findings (i.e., bugs, in the 
form of patches), and we will make our paper and code public after 
publication. However, we cannot disclose our tool at this moment because 
our research is still ongoing.

Regards,
Zilin Guan

Re: [v3 0/3] scsi: lpfc: Fix multiple memory leaks in error paths

[Markus Elfring]

>> You presented interesting development ideas.
>> Will any related concerns become relevant here?
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/researcher-guidelines.rst?h=v6.19-rc3#n5
>>
>> Did your analysis approach get a corresponding name?
…
> We are aware of these ethics requirements and strictly respect them.
> For example, we responsibly disclose our findings (i.e., bugs, in the 
> form of patches),

Thanks for your contributions.


>                   and we will make our paper and code public after 
> publication. However, we cannot disclose our tool at this moment because 
> our research is still ongoing.

Do the researcher guidelines indicate a need to point research activities out
in more explicit ways?

Does your email address indicate a relationship with the Southeast University?
Is the School of Information Science and Engineering involved here?

Regards,
Markus

Re: [v3 0/3] scsi: lpfc: Fix multiple memory leaks in error paths

[Zilin Guan]

On Sat, Jan 03, 2026 at 04:54:39PM +0100, Markus Elfring wrote:
> Do the researcher guidelines indicate a need to point research activities out
> in more explicit ways?

No, as our research does not constitute "active research on developer 
behavior", but rather consists of "good faith contributions". It is 
governed by and conducted in full compliance with both the Linux Kernel's 
Researcher Guidelines and the relevant security conference guidelines for 
vulnerability disclosure (e.g., IEEE S&P: https://sp2026.ieee-security.org/cfpapers.html).

I appreciate your engagement, but we must stay on point. Your frequent 
questions unrelated to the technical content of many my patches are 
causing distractions and creating noise in the discussion. Therefore, 
I will no longer respond to off-topic inquiries in this public channel.

Regards,
Zilin Guan