Re: [PATCH 2/3] zfcp: Trace plogi and prli within open port response as payload

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Preexisting out-of-bounds read of kernel memory due to unvalidated `log_start` and `log_length` fields from the FCP adapter response.
--

commit 9e601763da63b3c0c65512bab46a16c131e45614
Author: Steffen Maier <maier@linux.ibm.com>

zfcp: Trace plogi and prli within open port response as payload

This commit updates the zfcp debug trace to include PLOGI and PRLI content
from open port responses back-to-back in the payload trace record. It also
introduces a level argument to zfcp_dbf_pl_write() to control trace
verbosity and avoid flooding the log.

> diff --git a/drivers/s390/scsi/zfcp_dbf.c b/drivers/s390/scsi/zfcp_dbf.c
> index 89b859176b8bd..4217b74baa380 100644
> --- a/drivers/s390/scsi/zfcp_dbf.c
> +++ b/drivers/s390/scsi/zfcp_dbf.c

[ ... ]

> @@ -96,7 +101,27 @@ void zfcp_dbf_hba_fsf_res(char *tag, int level, struct zfcp_fsf_req *req)
>  
>  	rec->pl_len = q_head->log_length;
>  	zfcp_dbf_pl_write(dbf, (char *)q_pref + q_head->log_start,
> -			  rec->pl_len, "fsf_res", req->req_id);
> +			  rec->pl_len, "fsf_res", req->req_id,
> +			  ZFCP_DBF_PAY_LEVEL);

[Severity: High]
This is a pre-existing issue, but I noticed it while looking at this
modified call to zfcp_dbf_pl_write().

Are q_head->log_start and q_head->log_length validated before being used
to compute the source pointer and length here?

Since these fields are retrieved from the FCP adapter's response header,
could a malfunctioning or malicious adapter return arbitrarily large
values? If log_start + log_length exceeds the bounds of the req->qtcb
allocation, could this result in an out-of-bounds read of kernel memory
when copying into the trace buffer?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260611050550.796772-1-niharp@linux.ibm.com?part=2