Re: [PATCH 03/29] ibmvfc: split NVMe support into separate source file and add transport stubs

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The driver misuses the NVMe-FC transport private data API by overwriting the `fcp_req->private` pointer instead of storing data within the allocated memory, leading to a kernel panic during AEN teardown.
--

commit ff3f397be994beea2b3c34de8ca81ef76dd5fe89
Author: Tyrel Datwyler <tyreld@linux.ibm.com>

ibmvfc: split NVMe support into separate source file and add transport stubs

Rename ibmvfc.c to ibmvfc-core.c as first step in decoupling each
protocol from the core driver logic. Add ibmvfc-nvme.[ch] files, and
register an nvme_fc_port_template with empty callback stubs.

> diff --git a/drivers/scsi/ibmvscsi/ibmvfc-nvme.c b/drivers/scsi/ibmvscsi/ibmvfc-nvme.c
> new file mode 100644
> index 0000000000000..4a66cde8a8d20
> --- /dev/null
> +++ b/drivers/scsi/ibmvscsi/ibmvfc-nvme.c
[ ... ]
> +static struct nvme_fc_port_template ibmvfc_nvme_fc_transport = {
> +	.localport_delete	= ibmvfc_nvme_localport_delete,
> +	.remoteport_delete	= ibmvfc_nvme_remoteport_delete,
> +	.create_queue		= NULL,
> +	.delete_queue		= NULL,
> +	.ls_req			= ibmvfc_nvme_ls_req,
> +	.ls_abort		= ibmvfc_nvme_ls_abort,
> +	.fcp_io			= ibmvfc_nvme_fcp_io,
> +	.fcp_abort		= ibmvfc_nvme_fcp_abort,
> +	.map_queues		= NULL,
> +	.max_hw_queues		= IBMVFC_NVME_HW_QUEUES,
> +	.max_sgl_segments	= 1024,
> +	.max_dif_sgl_segments	= 64,
> +	.dma_boundary		= 0xFFFFFFFF,
> +	.local_priv_sz		= sizeof(struct ibmvfc_host *),
> +	.remote_priv_sz		= sizeof(struct ibmvfc_target *),
> +	.lsrqst_priv_sz		= sizeof(struct ibmvfc_event *),
> +	.fcprqst_priv_sz	= sizeof(struct ibmvfc_event *),

[Severity: High]
Will this misconfigure the transport private data API?

The NVMe-FC core allocates an 8-byte private data area for AEN requests using
kzalloc() in nvme_fc_init_aen_ops() based on the fcprqst_priv_sz requested
here.

If the driver later overwrites the fcp_req->private pointer directly with a
statically allocated ibmvfc_event pointer (e.g., fcp_req->private = evt;)
instead of storing it inside the allocated memory space, this will lead to a
kernel panic.

During controller teardown (e.g., device removal or transport error recovery),
nvme_fc_term_aen_ops() calls kfree(aen_op->fcp_req.private). Because the
pointer would have been overwritten, kfree() is called on the non-kmalloc'd
event pointer, resulting in a SLUB bug and memory leak.

> +};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260623013035.3436640-1-tyreld@linux.ibm.com?part=3