[PATCH] scsi: pm8001: fix IRQ leak using wrong index in MSI-X error path

[PATCH] scsi: pm8001: fix IRQ leak using wrong index in MSI-X error path

[Peng Hao]

pm8001_request_msix() requests each MSI-X IRQ with the loop index i. On a
request_irq() failure the cleanup loop "for (j = 0; j < i; j++)" calls
free_irq() with pci_irq_vector(pdev, i) and &irq_vector[i], i.e. the failed
index i instead of j. It therefore repeatedly tries to free the IRQ i that
was never successfully requested (triggering a free_irq() warning) while
the successfully requested IRQs 0..i-1 are never freed (leaked). Use j.

Fixes: 6cd60b37f72b ("[SCSI] pm80xx: Tasklets synchronization fix.")
Signed-off-by: Peng Hao <flyingpeng@tencent.com>
---
 drivers/scsi/pm8001/pm8001_init.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/pm8001/pm8001_init.c b/drivers/scsi/pm8001/pm8001_init.c
index e93ea76b565e..54b35893261a 100644
--- a/drivers/scsi/pm8001/pm8001_init.c
+++ b/drivers/scsi/pm8001/pm8001_init.c
@@ -1029,8 +1029,8 @@ static u32 pm8001_request_msix(struct pm8001_hba_info *pm8001_ha)
 			&(pm8001_ha->irq_vector[i]));
 		if (rc) {
 			for (j = 0; j < i; j++) {
-				free_irq(pci_irq_vector(pm8001_ha->pdev, i),
-					&(pm8001_ha->irq_vector[i]));
+				free_irq(pci_irq_vector(pm8001_ha->pdev, j),
+					 &pm8001_ha->irq_vector[j]);
 			}
 			pci_free_irq_vectors(pm8001_ha->pdev);
 			break;
-- 
2.43.7

Re: [PATCH] scsi: pm8001: fix IRQ leak using wrong index in MSI-X error path

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:

Pre-existing issues:
- [High] IRQ handlers are leaked and leave dangling pointers if initialization fails after IRQ allocation, leading to Use-After-Free.
- [High] Massive memory and resource leak in `pm8001_pci_probe()` when `pm8001_init_ccb_tag()` fails.
- [High] Memory leaks of CCB structures, DMA buffers, and `devices` array in probe error paths.
- [Medium] MSI-X vectors leaked in `pm8001_request_irq()` if falling back to INT-X.
--

commit 90250f8c5a096b2ef2642269b7762aa33f041c4c
Author: Peng Hao <flyingpenghao@gmail.com>

scsi: pm8001: fix IRQ leak using wrong index in MSI-X error path

This commit fixes an IRQ leak in pm8001_request_msix() by using the correct
loop index 'j' instead of 'i' when freeing IRQs on a request_irq() failure.
It ensures successfully requested IRQs are properly freed.

> diff --git a/drivers/scsi/pm8001/pm8001_init.c b/drivers/scsi/pm8001/pm8001_init.c
> index e93ea76b565e5..54b35893261a6 100644
> --- a/drivers/scsi/pm8001/pm8001_init.c
> +++ b/drivers/scsi/pm8001/pm8001_init.c
> @@ -1029,8 +1029,8 @@ static u32 pm8001_request_msix(struct pm8001_hba_info *pm8001_ha)
>  			&(pm8001_ha->irq_vector[i]));
>  		if (rc) {
>  			for (j = 0; j < i; j++) {
> -				free_irq(pci_irq_vector(pm8001_ha->pdev, i),
> -					&(pm8001_ha->irq_vector[i]));
> +				free_irq(pci_irq_vector(pm8001_ha->pdev, j),
> +					 &pm8001_ha->irq_vector[j]);
>  			}
>  			pci_free_irq_vectors(pm8001_ha->pdev);
>  			break;

[Severity: High]
This is a pre-existing issue, but does pm8001_alloc() leak IRQ handlers if
a subsequent allocation fails?

In pm8001_alloc(), pm8001_request_irq() successfully registers IRQs. If a
subsequent memory allocation fails, it returns an error:

drivers/scsi/pm8001/pm8001_init.c:pm8001_alloc() {
    ...
    err_out:
        return 1;
}

This prompts pm8001_pci_probe() to jump to failed_pci_alloc and call
pm8001_free():

drivers/scsi/pm8001/pm8001_init.c:pm8001_pci_probe() {
    ...
    err_out_ha_free:
        pm8001_free(pm8001_ha);
    err_out_free:
        kfree(sha);
    ...
}

However, pm8001_free() fails to call pm8001_free_irq():

drivers/scsi/pm8001/pm8001_init.c:pm8001_free() {
    ...
    bitmap_free(pm8001_ha->rsvd_tags);
    kfree(pm8001_ha);
}

Can this lead to a use-after-free if a shared interrupt triggers later and
pm8001_interrupt_handler_intx() dereferences the freed pm8001_ha and sha
structures?

[Severity: High]
This isn't a bug introduced by this patch, but does pm8001_pci_probe() bypass
cleanup labels when pm8001_init_ccb_tag() fails?

In pm8001_pci_probe(), if pm8001_init_ccb_tag() returns an error:

drivers/scsi/pm8001/pm8001_init.c:pm8001_pci_probe() {
    ...
    rc = pm8001_init_ccb_tag(pm8001_ha);
    if (rc)
        goto err_out_enable;
    ...
}

The code jumps directly to err_out_enable, which is below all proper cleanup
labels:

drivers/scsi/pm8001/pm8001_init.c:pm8001_pci_probe() {
    ...
    err_out_enable:
        return rc;
}

Does this cause a permanent resource leak of core driver structures like
pm8001_ha, shost, sha, and mapped PCI regions?

[Severity: High]
This is a pre-existing issue, but does pm8001_init_ccb_tag() leak CCB DMA
buffers on allocation failure?

If dma_alloc_coherent() fails for i > 0, it jumps to err_out:

drivers/scsi/pm8001/pm8001_init.c:pm8001_init_ccb_tag() {
    ...
    if (!pm8001_ha->ccb_info[i].buf_prd) {
        pm8001_dbg(pm8001_ha, FAIL,
                   "ccb prd memory allocation error\n");
        goto err_out;
    }
    ...
}

Will this leak previously allocated buffers since there is no loop to call
dma_free_coherent() on them?

Additionally, if pm8001_init_ccb_tag() succeeds but a later step in
pm8001_pci_probe() fails, the error path calls pm8001_free():

drivers/scsi/pm8001/pm8001_init.c:pm8001_free() {
    ...
    PM8001_CHIP_DISP->chip_iounmap(pm8001_ha);
    flush_workqueue(pm8001_wq);
    bitmap_free(pm8001_ha->rsvd_tags);
    kfree(pm8001_ha);
}

Does pm8001_free() permanently leak the devices array, ccb_info, and CCB DMA
buffers since it omits their teardown logic?

[Severity: Medium]
This isn't a bug introduced by this patch, but does pm8001_request_irq() leak
MSI-X vectors when falling back to INT-X?

If pm8001_setup_msix() successfully allocates vectors, but the subsequent check
fails:

drivers/scsi/pm8001/pm8001_init.c:pm8001_request_irq() {
    ...
    if (!pdev->msix_cap || !pci_msi_enabled())
        goto use_intx;
    ...
}

Does jumping to use_intx leak the MSI-X setup by not calling
pci_free_irq_vectors() before requesting legacy INT-X interrupts?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260828111729.58945-1-flyingpeng@tencent.com?part=1