Linux s390 Architecture development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Ajaykumar Rajappa" <ajaykr@linux.ibm.com>, linux-s390@vger.kernel.org
Cc: "Heiko Carstens" <hca@linux.ibm.com>,
	"Vasily Gorbik" <gor@linux.ibm.com>,
	"Alexander Gordeev" <agordeev@linux.ibm.com>,
	"Christian Borntraeger" <borntraeger@linux.ibm.com>
Subject: Re: [PATCH v6] zfcp: Fix integer underflow in status read buffer payload length
Date: Tue, 13 Oct 2026 02:08:29 +0000	[thread overview]
Message-ID: <sashiko-outbox-168846@kernel.org> (raw)
In-Reply-To: <20261013020122.48495-1-ajaykr@linux.ibm.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] scsi: zfcp: Build failure due to missing argument in zfcp_dbf_pl_write()
--

commit afc6c82d8c1360d9a43afb91aa19a62be2e21438
Author: Ajaykumar Rajappa <ajaykr@linux.ibm.com>

zfcp: Fix integer underflow in status read buffer payload length

This commit addresses integer underflows in zfcp_dbf_hba_fsf_uss() and
zfcp_dbf_san_in_els() when srb->length is smaller than the fixed header size.
It adds validations to avoid out-of-bounds reads or constructing invalid
scatterlists.

> diff --git a/drivers/s390/scsi/zfcp_dbf.c b/drivers/s390/scsi/zfcp_dbf.c
> index 81fb8af408e9c..a71dc0696d809 100644
> --- a/drivers/s390/scsi/zfcp_dbf.c
> +++ b/drivers/s390/scsi/zfcp_dbf.c
[ ... ]
> @@ -65,6 +65,47 @@ void zfcp_dbf_pl_write(struct zfcp_dbf *dbf, void *data, u16 length, char *area,
>  	spin_unlock(&dbf->pay_lock);
>  }
>  
[ ... ]
> +static void zfcp_dbf_srb_len_trace_if_bogus(struct zfcp_dbf *dbf,
> +					    struct fsf_status_read_buffer *srb,
> +					    u64 req_id)
> +{
> +	u32 raw_len = srb->length;
> +
> +	if (!raw_len ||
> +	    (raw_len >= offsetof(struct fsf_status_read_buffer, payload) &&
> +	     raw_len <= sizeof(*srb)))
> +		return;
> +
> +	zfcp_dbf_pl_write(dbf, &raw_len, sizeof(raw_len), "fsf_len", req_id);

[Severity: Low]
Does this call to zfcp_dbf_pl_write() result in a build regression?

The function zfcp_dbf_pl_write() requires 6 arguments, but only 5 are
provided here. The level argument is missing.

> +}
> +
[ ... ]
> @@ -253,13 +295,30 @@ void zfcp_dbf_hba_fsf_uss(char *tag, struct zfcp_fsf_req *req)
>  	rec->u.uss.s_id = ntoh24(srb->s_id);
>  	memcpy(&rec->u.uss.res4, &srb->res4, sizeof(rec->u.uss.res4));
>  
> -	/* status read buffer payload length */
> -	rec->pl_len = (!srb->length) ? 0 : srb->length -
> -			offsetof(struct fsf_status_read_buffer, payload);
> +	/* pl_len is the payload length (srb->length - pay_offset) as long as
> +	 * srb->length is valid. For a bogus srb->length it is only derived
> +	 * from it and the raw length is traced as "fsf_len" below.
> +	 */
> +	rec->pl_len = zfcp_dbf_srb_pl_len(srb);
> +
> +	/* Only access payload bytes when srb->length actually covers them.
> +	 * Bounds are checked on the full 32-bit value (before any u16
> +	 * truncation). An oversized srb->length is not dropped: the payload
> +	 * is traced up to the end of the payload array (diagnostic value).
> +	 */
> +	if (srb->length > pay_offset) {
> +		u32 cap_len = srb->length - pay_offset;
>  
> -	if (rec->pl_len)
> -		zfcp_dbf_pl_write(dbf, srb->payload.data, rec->pl_len,
> -				  "fsf_uss", req->req_id, ZFCP_DBF_PAY_LEVEL);
> +		if (cap_len > FSF_STATUS_READ_PAYLOAD_SIZE)
> +			cap_len = FSF_STATUS_READ_PAYLOAD_SIZE;
> +		zfcp_dbf_pl_write(dbf, srb->payload.data, cap_len,
> +				  "fsf_uss", req->req_id);

[Severity: Low]
Could this be missing the level argument (ZFCP_DBF_PAY_LEVEL) as well?

This call to zfcp_dbf_pl_write() drops the 6th argument that was present
in the previous implementation, which also causes a build regression.

> +	}

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

  reply	other threads:[~2026-10-13  2:08 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-13  2:01 [PATCH v6] zfcp: Fix integer underflow in status read buffer payload length Ajaykumar Rajappa
2026-10-13  2:08 ` sashiko-bot [this message]
  -- strict thread matches above, loose matches on Subject: below --
2026-10-13  2:38 Ajaykumar Rajappa
2026-10-13  2:54 ` sashiko-bot

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-168846@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=agordeev@linux.ibm.com \
    --cc=ajaykr@linux.ibm.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=linux-s390@vger.kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox