From: sashiko-bot@kernel.org
To: "Mohamed Khalfella" <mkhalfella@purestorage.com>
Cc: linux-nvme@lists.infradead.org
Subject: Re: [PATCH v7 04/17] nvmet: Implement CCR logpage
Date: Sat, 14 Nov 2026 03:20:48 +0000 [thread overview]
Message-ID: <sashiko-outbox-214097@kernel.org> (raw)
In-Reply-To: <20261114030454.2836543-5-mkhalfella@purestorage.com>
Thank you for your contribution! Sashiko AI review found 2 potential
issues to consider:
- [High] nvmet: uninitialized SGL tail leak in
nvmet_execute_get_log_page_ccr()
- [Medium] nvmet: premature CCR cleanup before SGL copy in
nvmet_execute_get_log_page_ccr()
--
commit bd4c242dbfa9b91e0bb3eb6e57be8d11c6a19d19
Author: Mohamed Khalfella <mkhalfella@purestorage.com>
nvmet: Implement CCR logpage
This commit implements the Cross-Controller Reset (CCR) log page (LID 0x1e)
for the NVMe target and advertises it in the Supported Log Pages log.
> diff --git a/drivers/nvme/target/admin-cmd.c b/drivers/nvme/target/admin-cmd.c
> index 3df9db454db9c..25c320752d2a7 100644
> --- a/drivers/nvme/target/admin-cmd.c
> +++ b/drivers/nvme/target/admin-cmd.c
[ ... ]
> @@ -617,6 +618,46 @@ static void nvmet_execute_get_log_page_features(struct nvmet_req *req)
> nvmet_req_complete(req, status);
> }
>
> +static void nvmet_execute_get_log_page_ccr(struct nvmet_req *req)
> +{
> + struct nvmet_ctrl *ctrl = req->sq->ctrl;
> + struct nvmet_ccr *ccr;
> + struct nvme_ccr_log *log;
> + int index = 0;
> + u16 status;
> +
> + log = kzalloc_obj(*log);
> + if (!log) {
> + status = NVME_SC_INTERNAL;
> + goto out;
> + }
> +
> + mutex_lock(&ctrl->lock);
> + list_for_each_entry(ccr, &ctrl->ccr_list, entry) {
> + u8 flags = NVME_CCR_FLAGS_VALIDATED | NVME_CCR_FLAGS_INITIATED;
> + u8 ccr_status = ccr->ctrl ? NVME_CCR_STATUS_IN_PROGRESS :
> + NVME_CCR_STATUS_SUCCESS;
> +
> + log->entries[index].icid = cpu_to_le16(ccr->icid);
> + log->entries[index].ciu = ccr->ciu;
> + log->entries[index].acid = cpu_to_le16(0xffff);
> + log->entries[index].ccrs = ccr_status;
> + log->entries[index].ccrf = flags;
> + index++;
> + }
> +
> + /* Cleanup completed CCRs if requested */
> + if (req->cmd->get_log_page.lsp & 0x1)
> + nvmet_ctrl_cleanup_ccrs(ctrl, false);
> + mutex_unlock(&ctrl->lock);
[Severity: Medium]
Can nvmet_ctrl_cleanup_ccrs() discard completed CCR entries when the log
page fails to copy to the host?
nvmet_execute_get_log_page() only checks that req->transfer_len matches the
command's NUMDL/NUMDU length. If a host requests fewer than sizeof(*log)
bytes (for example, reading the 8-byte header) with LSP bit 0 set,
nvmet_ctrl_cleanup_ccrs() frees all completed entries from ctrl->ccr_list
before nvmet_copy_to_sgl() fails with NVME_SC_SGL_INVALID_DATA, so the host
permanently loses those completion records.
> +
> + log->ne = cpu_to_le16(index);
> + status = nvmet_copy_to_sgl(req, 0, log, sizeof(*log));
[Severity: High]
Does this leak uninitialized target kernel memory when the host requests
more than sizeof(*log) bytes?
Transports allocate req->sg for req->transfer_len bytes via sgl_alloc()
with GFP_KERNEL (without __GFP_ZERO). Because nvmet_execute_get_log_page()
only checks that req->transfer_len matches NUMDL/NUMDU and
nvmet_execute_get_log_page_ccr() neither rejects req->transfer_len !=
sizeof(*log) (like nvmet_execute_get_log_page_rmi() and
nvmet_execute_get_log_page_smart()) nor zeroes trailing SGL bytes,
requesting more than 4096 bytes copies sizeof(*log) at offset 0 and returns
the remaining uninitialized scatterlist pages to the host.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261114030454.2836543-1-mkhalfella@purestorage.com?part=4
next prev parent reply other threads:[~2026-11-14 3:20 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-14 3:04 [PATCH v7 00/17] TP8028 Rapid Path Failure Recovery Mohamed Khalfella
2026-11-14 3:04 ` [PATCH v7 01/17] nvmet: Rapid Path Failure Recovery set controller identify fields Mohamed Khalfella
2026-11-14 3:17 ` sashiko-bot
2026-11-14 3:04 ` [PATCH v7 02/17] nvmet/debugfs: Export controller CIU and CIRN via debugfs Mohamed Khalfella
2026-11-14 3:12 ` sashiko-bot
2026-11-14 3:04 ` [PATCH v7 03/17] nvmet: Implement CCR nvme command Mohamed Khalfella
2026-11-14 3:30 ` sashiko-bot
2026-11-14 3:04 ` [PATCH v7 04/17] nvmet: Implement CCR logpage Mohamed Khalfella
2026-11-14 3:20 ` sashiko-bot [this message]
2026-11-14 3:04 ` [PATCH v7 05/17] nvmet: Send an AEN on CCR completion Mohamed Khalfella
2026-11-14 3:04 ` [PATCH v7 06/17] nvme: Rapid Path Failure Recovery read controller identify fields Mohamed Khalfella
2026-11-14 3:04 ` [PATCH v7 07/17] nvme: Introduce FENCING and FENCED controller states Mohamed Khalfella
2026-11-14 3:29 ` sashiko-bot
2026-11-14 3:04 ` [PATCH v7 08/17] nvme: Implement cross-controller reset recovery Mohamed Khalfella
2026-11-14 3:26 ` sashiko-bot
2026-11-14 3:04 ` [PATCH v7 09/17] nvme: Implement cross-controller reset completion Mohamed Khalfella
2026-11-14 3:29 ` sashiko-bot
2026-11-14 3:04 ` [PATCH v7 10/17] nvme-tcp: Use CCR to recover controller that hits an error Mohamed Khalfella
2026-11-14 3:38 ` sashiko-bot
2026-11-14 3:04 ` [PATCH v7 11/17] nvme-rdma: " Mohamed Khalfella
2026-11-14 3:04 ` [PATCH v7 12/17] nvme-fc: start error recovery instead of aborting timed out IOs Mohamed Khalfella
2026-11-14 3:46 ` sashiko-bot
2026-11-14 3:04 ` [PATCH v7 13/17] nvme-fc: perform error recovery directly from ioerr_work Mohamed Khalfella
2026-11-14 3:31 ` sashiko-bot
2026-11-14 3:04 ` [PATCH v7 14/17] nvme-fc: Use CCR to recover controller that hits an error Mohamed Khalfella
2026-11-14 3:38 ` sashiko-bot
2026-11-14 3:04 ` [PATCH v7 15/17] nvme-fc: Hold inflight requests while in FENCING state Mohamed Khalfella
2026-11-14 3:04 ` [PATCH v7 16/17] nvmet: Add support for CQT to nvme target Mohamed Khalfella
2026-11-14 3:04 ` [PATCH v7 17/17] nvme: Add support for CQT to nvme host Mohamed Khalfella
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-214097@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=mkhalfella@purestorage.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.