Re: [PATCH v2] target/stat: implement scsiPortBusyStatuses counter

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Critical] NULL pointer dereference in `ib_srpt.c` error path when handling a malformed SRP command.
--

--- Patch [1]: [PATCH v2] target/stat: implement scsiPortBusyStatuses counter ---
commit 7d5200afbb36f3291f84cfd7445e77cbcd9a96de
Author: TanZheng <tanzheng@kylinos.cn>

target/stat: implement scsiPortBusyStatuses counter

Implement RFC 4455 scsiPortBusyStatuses (ConfigFS busy_count) by adding a
per-CPU busy_statuses counter to scsi_port_stats, incrementing it when
the target sends SAM_STAT_BUSY, and summing all CPUs in the show handler.

> diff --git a/drivers/target/target_core_transport.c b/drivers/target/target_core_transport.c
> index fad03a15c969e..bab5ee81817b5 100644
> --- a/drivers/target/target_core_transport.c
> +++ b/drivers/target/target_core_transport.c
[ ... ]
> @@ -829,6 +829,20 @@ void transport_copy_sense_to_cmd(struct se_cmd *cmd, unsigned char *sense)
>  }
>  EXPORT_SYMBOL(transport_copy_sense_to_cmd);
>  
> +static int target_queue_status(struct se_cmd *cmd)
> +{
> +	int ret;
> +	struct se_lun *lun = cmd->se_lun;
> +	u8 scsi_status = cmd->scsi_status;
> +	u32 flags = cmd->se_cmd_flags;
> +
> +	ret = cmd->se_tfo->queue_status(cmd);

[Severity: Critical]
This is a pre-existing issue, but does this lead to a null pointer dereference
when handling a malformed SRP command in ib_srpt.c?

If an initiator sends an SRP command with a malformed descriptor table,
srpt_get_desc_tbl() fails, causing srpt_handle_cmd() to jump to the busy
label before target_init_cmd() has initialized cmd->se_tfo:

drivers/infiniband/ulp/srpt/ib_srpt.c:srpt_handle_cmd() {
	...
	rc = srpt_get_desc_tbl(...);
	if (rc) {
		...
		goto busy;
	}
	...
busy:
	target_send_busy(cmd);
}

This calls target_send_busy(), which calls target_queue_status() here,
unconditionally dereferencing cmd->se_tfo->queue_status(cmd) while
cmd->se_tfo is still zero-initialized.

Could a remote initiator trigger a denial of service by sending a maliciously
crafted packet?

> +	if (!ret)
> +		target_stat_count_sent_status(lun, scsi_status, flags);
> +
> +	return ret;
> +}
> +

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260709071805.769860-1-kensanya@163.com?part=1