From: sashiko-bot@kernel.org
To: "Artem Dinaburg" <artem@trailofbits.com>
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH 6.6.y] scsi: lpfc: Handle mailbox timeouts in lpfc_get_sfp_info
Date: Wed, 30 Sep 2026 02:56:00 +0000 [thread overview]
Message-ID: <20260930025600.B219A1F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260930024505.96440-1-artem@trailofbits.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] scsi: lpfc: Use-After-Free and data race due to lockless mbox assignment
- [Medium] scsi: lpfc: memory leak of mbox and mpsave on synchronous issue failure
--
commit 7e8ff891a4886b3f83580607c0dc5ee36c6f7ce1
Author: Justin Tee <justin.tee@broadcom.com>
scsi: lpfc: Handle mailbox timeouts in lpfc_get_sfp_info
This commit adds checks for the MBX_TIMEOUT return code in lpfc_get_sfp_info,
avoiding unconditional frees of timed-out mailbox commands. The timeout is
also increased from 30 to 60 seconds to accommodate boot scripts.
Link: https://lore.kernel.org/r/20240628172011.25921-6-justintee8345@gmail.com
> diff --git a/drivers/scsi/lpfc/lpfc_els.c b/drivers/scsi/lpfc/lpfc_els.c
> index 2e9972a587810..d319df7d36137 100644
> --- a/drivers/scsi/lpfc/lpfc_els.c
> +++ b/drivers/scsi/lpfc/lpfc_els.c
> @@ -7381,7 +7384,8 @@ int lpfc_get_sfp_info_wait(struct lpfc_hba *phba,
>
> error:
> mbox->ctx_buf = mpsave;
[Severity: High]
If lpfc_sli_issue_mbox_wait() times out, it transfers ownership of the mailbox
by setting:
drivers/scsi/lpfc/lpfc_sli.c:lpfc_sli_issue_mbox_wait() {
...
} else {
retval = MBX_TIMEOUT;
pmboxq->mbox_cmpl = lpfc_sli_def_mbox_cmpl;
}
...
}
Does modifying mbox->ctx_buf locklessly here introduce a data race with the
asynchronous completion handler?
If the hardware completes the mailbox command and lpfc_sli_def_mbox_cmpl()
runs concurrently, could it read an invalid payload pointer leading to a crash
in lpfc_mbox_rsrc_cleanup(), or cause a use-after-free write on the freed
mbox struct?
> - lpfc_mbox_rsrc_cleanup(phba, mbox, MBOX_THD_UNLOCKED);
> + if (mbox->mbox_flag & LPFC_MBX_WAKE)
> + lpfc_mbox_rsrc_cleanup(phba, mbox, MBOX_THD_UNLOCKED);
[Severity: Medium]
When lpfc_sli_issue_mbox_wait() returns MBX_NOT_FINISHED, the LPFC_MBX_WAKE
flag is not set since the command failed to queue.
Will skipping lpfc_mbox_rsrc_cleanup() here leak the mbox and mpsave memory
on synchronous failures, since the async completion handler will never run to
clean them up?
> return rc;
>
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260930024505.96440-1-artem@trailofbits.com?part=1
next prev parent reply other threads:[~2026-09-30 2:56 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-30 2:45 [PATCH 6.6.y] scsi: lpfc: Handle mailbox timeouts in lpfc_get_sfp_info Artem Dinaburg
2026-09-30 2:56 ` sashiko-bot [this message]
2026-10-01 13:52 ` Sasha Levin
2026-10-02 17:50 ` Artem Dinaburg
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=20260930025600.B219A1F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=artem@trailofbits.com \
--cc=linux-scsi@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.