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
next prev parent 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