[PATCH 6.1.y] scsi: lpfc: Fix use-after-free of mboxq in lpfc_sli4_driver_resource_setup()

[PATCH 6.1.y] scsi: lpfc: Fix use-after-free of mboxq in lpfc_sli4_driver_resource_setup()

[Andrey Misiurov]

The 6.1.y backport of upstream commit 1bd28625e25b ("scsi: lpfc: Fix
memory leak in lpfc_sli4_driver_resource_setup()") added the new
mempool_free() of mboxq in the wrong place. Upstream frees mboxq after
the error handling of lpfc_get_sli4_parameters(). In 6.1.y the hunk
landed before that call, right after the NVMET WWN loop:

	mempool_free(mboxq, phba->mbox_mem_pool);
	lpfc_nvme_mod_param_dep(phba);
	rc = lpfc_get_sli4_parameters(phba, mboxq);

mbox_mem_pool is created a few lines earlier in the same function, so
the pool is full and mempool_free() really kfree()s mboxq.
lpfc_get_sli4_parameters() then builds and issues a mailbox command in
freed memory. This happens on every SLI4 probe. Its error paths also
free mboxq a second time.

Move the mempool_free() to where upstream and the other stable trees
have it.

Fixes: 299f5baa1321 ("scsi: lpfc: Fix memory leak in lpfc_sli4_driver_resource_setup()")
Signed-off-by: Andrey Misiurov <andrey.misyrov@gmail.com>
---
 drivers/scsi/lpfc/lpfc_init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c
index 13ebbe4..fc5a640 100644
--- a/drivers/scsi/lpfc/lpfc_init.c
+++ b/drivers/scsi/lpfc/lpfc_init.c
@@ -8175,7 +8175,6 @@ lpfc_sli4_driver_resource_setup(struct lpfc_hba *phba)
 			}
 		}
 	}
-	mempool_free(mboxq, phba->mbox_mem_pool);
 
 	lpfc_nvme_mod_param_dep(phba);
 
@@ -8209,6 +8208,7 @@ lpfc_sli4_driver_resource_setup(struct lpfc_hba *phba)
 			goto out_free_bsmbx;
 		}
 	}
+	mempool_free(mboxq, phba->mbox_mem_pool);
 
 	/*
 	 * 1 for cmd, 1 for rsp, NVME adds an extra one
-- 
2.43.7

Re: [PATCH 6.1.y] scsi: lpfc: Fix use-after-free of mboxq in lpfc_sli4_driver_resource_setup()

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] scsi: lpfc: Double free / UAF of mboxq on mailbox timeout in lpfc_get_sli4_parameters()
--

commit 7386b919d763fc6f447906aaee405cec863dac39
Author: Andrey Misiurov <andrey.misyrov@gmail.com>

scsi: lpfc: Fix use-after-free of mboxq in lpfc_sli4_driver_resource_setup()

This commit moves the mempool_free() of mboxq in 
lpfc_sli4_driver_resource_setup() after the error handling for 
lpfc_get_sli4_parameters() to fix a previous incorrect backport.

> diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c
> index 13ebbe4a71c47..fc5a640b7f742 100644
> --- a/drivers/scsi/lpfc/lpfc_init.c
> +++ b/drivers/scsi/lpfc/lpfc_init.c
> @@ -8175,7 +8175,6 @@ lpfc_sli4_driver_resource_setup(struct lpfc_hba *phba)
>  			}
>  		}
>  	}
> -	mempool_free(mboxq, phba->mbox_mem_pool);
>  
>  	lpfc_nvme_mod_param_dep(phba);
>  

[ ... ]

> @@ -8209,6 +8208,7 @@ lpfc_sli4_driver_resource_setup(struct lpfc_hba *phba)
>  			goto out_free_bsmbx;
>  		}
>  	}
> +	mempool_free(mboxq, phba->mbox_mem_pool);

[Severity: High]
Does this unconditionally free mboxq even when lpfc_get_sli4_parameters()
encounters a timeout?

If the mailbox command issued by lpfc_get_sli4_parameters() times out, it
returns MBX_TIMEOUT. On this path, the driver retains the mboxq and 
delegates cleanup to the asynchronous completion handler:

drivers/scsi/lpfc/lpfc_sli.c:lpfc_sli_issue_mbox_wait() {
    ...
		} else {
			retval = MBX_TIMEOUT;
			pmboxq->mbox_cmpl = lpfc_sli_def_mbox_cmpl;
		}
    ...
}

Because mboxq is freed unconditionally here on the success path (and also
on the error goto paths above this), could this lead to a double-free and
use-after-free when the async handler later attempts to clean it up?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261008184328.2857037-1-andrey.misyrov@gmail.com?part=1

Re: [PATCH 6.1.y] scsi: lpfc: Fix use-after-free of mboxq in lpfc_sli4_driver_resource_setup()

[Sasha Levin]

> Move the mempool_free() to where upstream and the other stable trees
> have it.

Thanks for the fix. Ideally a maintainer could ack it.

-- 
Thanks,
Sasha

Re: [PATCH 6.1.y] scsi: lpfc: Fix use-after-free of mboxq in lpfc_sli4_driver_resource_setup()

[Abdun Nihaal]

On Thu, Oct 08, 2026 at 08:43:28PM +0200, Andrey Misiurov wrote:
> Move the mempool_free() to where upstream and the other stable trees
> have it.
> 
> Fixes: 299f5baa1321 ("scsi: lpfc: Fix memory leak in lpfc_sli4_driver_resource_setup()")
> Signed-off-by: Andrey Misiurov <andrey.misyrov@gmail.com>

I'm the author of the upstream patch (not a maintainer). 
The fix looks good to me. Thanks for catching this.

Acked-by: Abdun Nihaal <nihaal@cse.iitm.ac.in>

How did you detect this? Just curious.

Regards,
Nihaal

Re: [PATCH 6.1.y] scsi: lpfc: Fix use-after-free of mboxq in lpfc_sli4_driver_resource_setup()

[Андрей Мисюров]

On Sat, Oct 10, 2026 at 11:19:35AM +0530, Abdun Nihaal wrote:
> How did you detect this? Just curious.

Hi Nihaal,

Thanks for the ack!

I work on kernel live-patching and hit this while backporting the
CVE-2026-72087 fix. I just compared the 6.1.y version with the mainline.

Regards,
Andrey