From: sashiko-bot@kernel.org
To: "Nigel Kirkland" <nkirkland2304@gmail.com>
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH v6 1/8] lpfc: Fix use-after-free in lpfc_cmpl_ct_cmd_vmid
Date: Tue, 13 Oct 2026 00:03:21 +0000 [thread overview]
Message-ID: <sashiko-outbox-168765@kernel.org> (raw)
In-Reply-To: <20261013001648.62289-2-nkirkland2304@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] scsi: lpfc: evaluation of uninitialized response payload on transport error
--
commit c46419e38a4d473126adc74a9b8003eb31bdd1e9
Author: Nigel Kirkland <nkirkland2304@gmail.com>
lpfc: Fix use-after-free in lpfc_cmpl_ct_cmd_vmid
This commit resolves a use-after-free issue in lpfc_cmpl_ct_cmd_vmid by
removing an early call to lpfc_ct_free_iocb for SLI_CTAS_DALLAPP_ID commands.
The previous code freed the IOCB and then continued to access the response
buffer.
> diff --git a/drivers/scsi/lpfc/lpfc_ct.c b/drivers/scsi/lpfc/lpfc_ct.c
> index 0734ab3be3e30..f709e50875770 100644
> --- a/drivers/scsi/lpfc/lpfc_ct.c
> +++ b/drivers/scsi/lpfc/lpfc_ct.c
> @@ -3576,8 +3576,6 @@ lpfc_cmpl_ct_cmd_vmid(struct lpfc_hba *phba, struct lpfc_iocbq *cmdiocb,
> int i;
>
> cmd = be16_to_cpu(ctcmd->CommandResponse.bits.CmdRsp);
> - if (cmd == SLI_CTAS_DALLAPP_ID)
> - lpfc_ct_free_iocb(phba, cmdiocb);
>
> if (lpfc_els_chk_latt(vport) || get_job_ulpstatus(phba, rspiocb)) {
> if (cmd != SLI_CTAS_DALLAPP_ID)
[Severity: Medium]
Does this code evaluate uninitialized memory if there is a transport error?
If get_job_ulpstatus() indicates a transport error, the device did not populate
the response buffer. Since the error handler is intentionally bypassed for
SLI_CTAS_DALLAPP_ID:
drivers/scsi/lpfc/lpfc_ct.c:lpfc_cmpl_ct_cmd_vmid() {
if (lpfc_els_chk_latt(vport) || get_job_ulpstatus(phba, rspiocb)) {
if (cmd != SLI_CTAS_DALLAPP_ID)
goto free_res;
}
...
The code will then fall through to the next check:
if (be16_to_cpu(rsp) == SLI_CT_RESPONSE_FS_RJT) {
...
And evaluate rsp, ctrsp->ReasonCode, and ctrsp->Explanation from the outp->virt
buffer. Since lpfc_alloc_ct_rsp() allocates this buffer via lpfc_mbuf_alloc()
without zero-initialization, this reads uninitialized memory.
Could this lead to non-deterministic behavior, such as spuriously retrying the
command or incorrectly assuming success and deregistering all VMID app IDs?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261013001648.62289-1-nkirkland2304@gmail.com?part=1
next prev parent reply other threads:[~2026-10-13 0:03 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-13 0:16 [PATCH v6 0/8] lpfc: Update lpfc to revision 15.0.0.1 Nigel Kirkland
2026-10-13 0:16 ` [PATCH v6 1/8] lpfc: Fix use-after-free in lpfc_cmpl_ct_cmd_vmid Nigel Kirkland
2026-10-13 0:03 ` sashiko-bot [this message]
2026-10-13 0:16 ` [PATCH v6 2/8] lpfc: Early return out of lpfc_els_abort when HBA_SETUP flag is not set Nigel Kirkland
2026-10-13 0:05 ` sashiko-bot
2026-10-13 0:16 ` [PATCH v6 3/8] lpfc: Fix kernel oops when unmapping scsi dma buffers for an aborted cmd Nigel Kirkland
2026-10-13 0:07 ` sashiko-bot
2026-10-13 0:16 ` [PATCH v6 4/8] lpfc: Check fc4_xpt_flags before decrementing ndlp kref on FDISC error Nigel Kirkland
2026-10-13 0:16 ` [PATCH v6 5/8] lpfc: Rework I/O flush ordering when unloading driver Nigel Kirkland
2026-10-13 0:12 ` sashiko-bot
2026-10-13 0:16 ` [PATCH v6 6/8] lpfc: Refactor calls on fc_disctmo to lpfc_set_disctmo in RSCN handler Nigel Kirkland
2026-10-13 0:16 ` [PATCH v6 7/8] lpfc: Update correct ndlp refcnt when rejecting an unsolicited PLOGI Nigel Kirkland
2026-10-13 0:13 ` sashiko-bot
2026-10-13 0:16 ` [PATCH v6 8/8] lpfc: Update lpfc version to 15.0.0.1 Nigel Kirkland
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=sashiko-outbox-168765@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=nkirkland2304@gmail.com \
--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.