public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Sasha Levin <sashal@kernel.org>
To: patches@lists.linux.dev, stable@vger.kernel.org
Cc: Justin Tee <justin.tee@broadcom.com>,
	"Martin K . Petersen" <martin.petersen@oracle.com>,
	Sasha Levin <sashal@kernel.org>,
	james.smart@broadcom.com, dick.kennedy@broadcom.com,
	linux-scsi@vger.kernel.org
Subject: [PATCH AUTOSEL 6.16-5.4] scsi: lpfc: Check for hdwq null ptr when cleaning up lpfc_vport structure
Date: Tue,  5 Aug 2025 09:09:01 -0400	[thread overview]
Message-ID: <20250805130945.471732-26-sashal@kernel.org> (raw)
In-Reply-To: <20250805130945.471732-1-sashal@kernel.org>

From: Justin Tee <justin.tee@broadcom.com>

[ Upstream commit 6698796282e828733cde3329c887b4ae9e5545e9 ]

If a call to lpfc_sli4_read_rev() from lpfc_sli4_hba_setup() fails, the
resultant cleanup routine lpfc_sli4_vport_delete_fcp_xri_aborted() may
occur before sli4_hba.hdwqs are allocated.  This may result in a null
pointer dereference when attempting to take the abts_io_buf_list_lock for
the first hardware queue.  Fix by adding a null ptr check on
phba->sli4_hba.hdwq and early return because this situation means there
must have been an error during port initialization.

Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Link: https://lore.kernel.org/r/20250618192138.124116-4-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

So, the issue is:
1. During driver initialization in `lpfc_sli4_pci_probe()` (around line
   14868), `lpfc_sli4_hba_setup()` is called
2. Inside `lpfc_sli4_hba_setup()` at line 8517, `lpfc_sli4_read_rev()`
   is called
3. If `lpfc_sli4_read_rev()` fails, we goto `out_free_mbox` which
   returns error
4. The queue creation (`lpfc_sli4_queue_create()` at line 8811) that
   allocates `hdwq` is never reached
5. When the error is returned to `lpfc_sli4_pci_probe()`, it goes to
   `out_free_sysfs_attr`
6. This error path calls `lpfc_destroy_shost()` -> `destroy_port()` ->
   `lpfc_cleanup()` -> `lpfc_cleanup_vports_rrqs()` ->
   `lpfc_sli4_vport_delete_fcp_xri_aborted()`
7. `lpfc_sli4_vport_delete_fcp_xri_aborted()` tries to access
   `phba->sli4_hba.hdwq[idx]` which is NULL, causing a null pointer
   dereference

## Backport Analysis

**YES**

This commit should be backported to stable kernel trees for the
following reasons:

1. **Critical Bug Fix**: The commit fixes a NULL pointer dereference
   that can cause a kernel crash. This is a serious bug that affects
   system stability when the lpfc driver fails to initialize properly.

2. **Clear Error Path Issue**: The bug occurs in a well-defined error
   handling path - when `lpfc_sli4_read_rev()` fails during HBA setup.
   This is not a theoretical issue but can happen in real-world
   scenarios when hardware initialization fails.

3. **Small and Contained Fix**: The fix is minimal - just adding a NULL
   check with early return (4 lines of code). This follows the stable
   kernel criteria of being a small, focused fix that addresses a
   specific issue.

4. **No Architectural Changes**: The fix doesn't introduce any new
   features or change the driver architecture. It simply adds defensive
   programming to prevent accessing unallocated memory.

5. **Low Risk of Regression**: The added check `if
   (!phba->sli4_hba.hdwq) return;` is safe - if hdwq is NULL, the
   function cannot proceed anyway. The early return prevents the crash
   without affecting normal operation when hdwq is properly allocated.

6. **Matches Stable Rules**: According to stable kernel rules, fixes for
   kernel crashes and oopses are prime candidates for backporting. This
   commit specifically prevents a NULL pointer dereference that would
   result in a kernel oops.

7. **Driver Initialization Robustness**: The issue affects error
   handling during driver initialization, which is a critical path.
   Failures during initialization should be handled gracefully without
   causing system crashes.

The commit message clearly describes the problem scenario and the
solution, making it easy for stable maintainers to understand the
importance of this fix. The fact that it adds a defensive check before
dereferencing a pointer that may not be allocated in error paths is
exactly the type of robustness improvement that stable kernels should
receive.

 drivers/scsi/lpfc/lpfc_scsi.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/scsi/lpfc/lpfc_scsi.c b/drivers/scsi/lpfc/lpfc_scsi.c
index 8acb744febcd..31a9f142bcb9 100644
--- a/drivers/scsi/lpfc/lpfc_scsi.c
+++ b/drivers/scsi/lpfc/lpfc_scsi.c
@@ -390,6 +390,10 @@ lpfc_sli4_vport_delete_fcp_xri_aborted(struct lpfc_vport *vport)
 	if (!(vport->cfg_enable_fc4_type & LPFC_ENABLE_FCP))
 		return;
 
+	/* may be called before queues established if hba_setup fails */
+	if (!phba->sli4_hba.hdwq)
+		return;
+
 	spin_lock_irqsave(&phba->hbalock, iflag);
 	for (idx = 0; idx < phba->cfg_hdw_queue; idx++) {
 		qp = &phba->sli4_hba.hdwq[idx];
-- 
2.39.5


  parent reply	other threads:[~2025-08-05 13:10 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20250805130945.471732-1-sashal@kernel.org>
2025-08-05 13:08 ` [PATCH AUTOSEL 6.16-5.4] scsi: bfa: Double-free fix Sasha Levin
2025-08-05 13:08 ` [PATCH AUTOSEL 6.16-6.12] scsi: lpfc: Ensure HBA_SETUP flag is used only for SLI4 in dev_loss_tmo_callbk Sasha Levin
2025-08-05 13:09 ` Sasha Levin [this message]
2025-08-05 13:09 ` [PATCH AUTOSEL 6.16-6.15] scsi: pm80xx: Free allocated tags after failure Sasha Levin
2025-08-05 13:09 ` [PATCH AUTOSEL 6.16-6.1] scsi: mpi3mr: Correctly handle ATA device errors Sasha Levin
2025-08-05 13:09 ` [PATCH AUTOSEL 6.16-5.4] scsi: mpt3sas: " Sasha Levin
2025-08-05 13:09 ` [PATCH AUTOSEL 6.16-5.4] scsi: libiscsi: Initialize iscsi_conn->dd_data only if memory is allocated Sasha Levin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250805130945.471732-26-sashal@kernel.org \
    --to=sashal@kernel.org \
    --cc=dick.kennedy@broadcom.com \
    --cc=james.smart@broadcom.com \
    --cc=justin.tee@broadcom.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=patches@lists.linux.dev \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox