Linux s390 Architecture development
 help / color / mirror / Atom feed
From: Ajaykumar Rajappa <ajaykr@linux.ibm.com>
To: linux-s390@vger.kernel.org, sashiko-reviews@lists.linux.dev
Cc: Ajaykumar Rajappa <ajaykr@linux.ibm.com>
Subject: [PATCH v3] zfcp: Fix integer underflow in status read buffer payload length
Date: Thu, 24 Sep 2026 14:24:00 +0200	[thread overview]
Message-ID: <20260924122400.1185067-1-ajaykr@linux.ibm.com> (raw)

zfcp_dbf_hba_fsf_uss() only guards against a zero-length status read
buffer. If srb->length is non-zero but smaller than the fixed header
size of struct fsf_status_read_buffer, subtracting the payload offset
underflows and can result in an out-of-bounds read from
srb->payload.data.

zfcp_dbf_san_in_els() has the same problem. The underflowed value is
used as the scatterlist payload length, potentially causing accesses
beyond the reported status read buffer.

Prevent both underflows by validating srb->length before subtracting the
payload offset. If the reported status read buffer length does not reach
the payload area, treat the payload as empty rather than performing the
subtraction. This avoids the unsigned underflow and ensures that no
payload data is processed or accessed beyond the reported buffer.

Skip scatterlist setup and payload tracing when no valid payload exists.
If the reported status read buffer length does not reach the payload
area, no scatterlist is initialized and zfcp_dbf_san() is called
without payload data, preventing any access beyond the reported buffer.

For valid payloads, preserve the existing tracing behavior by continuing
to initialize the scatterlist and pass the computed payload length to
zfcp_dbf_san().

Signed-off-by: Ajaykumar Rajappa <ajaykr@linux.ibm.com>
---
 drivers/s390/scsi/zfcp_dbf.c | 19 ++++++++++++-------
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/s390/scsi/zfcp_dbf.c b/drivers/s390/scsi/zfcp_dbf.c
index 81fb8af408e9..5ae1302b993e 100644
--- a/drivers/s390/scsi/zfcp_dbf.c
+++ b/drivers/s390/scsi/zfcp_dbf.c
@@ -223,6 +223,7 @@ void zfcp_dbf_hba_fsf_uss(char *tag, struct zfcp_fsf_req *req)
 	struct zfcp_dbf_hba *rec = &dbf->hba_buf;
 	static int const level = 2;
 	unsigned long flags;
+	const u32 pay_offset = offsetof(struct fsf_status_read_buffer, payload);
 
 	if (unlikely(!debug_level_enabled(dbf->hba, level)))
 		return;
@@ -254,8 +255,8 @@ void zfcp_dbf_hba_fsf_uss(char *tag, struct zfcp_fsf_req *req)
 	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);
+	rec->pl_len = (srb->length < pay_offset) ? 0 :
+		      (u16)(srb->length - pay_offset);
 
 	if (rec->pl_len)
 		zfcp_dbf_pl_write(dbf, srb->payload.data, rec->pl_len,
@@ -716,15 +717,19 @@ void zfcp_dbf_san_in_els(char *tag, struct zfcp_fsf_req *fsf)
 		(struct fsf_status_read_buffer *) fsf->data;
 	u16 length;
 	struct scatterlist sg;
+	const u32 pay_offset = offsetof(struct fsf_status_read_buffer, payload);
 
 	if (unlikely(!debug_level_enabled(dbf->san, ZFCP_DBF_SAN_LEVEL)))
 		return;
 
-	length = (u16)(srb->length -
-			offsetof(struct fsf_status_read_buffer, payload));
-	sg_init_one(&sg, srb->payload.data, length);
-	zfcp_dbf_san(tag, dbf, "san_els", &sg, ZFCP_DBF_SAN_ELS, length,
-		     fsf->req_id, ntoh24(srb->d_id), length);
+	length = (srb->length < pay_offset) ? 0 :
+		 (u16)(srb->length - pay_offset);
+
+	if (length)
+		sg_init_one(&sg, srb->payload.data, length);
+
+	zfcp_dbf_san(tag, dbf, "san_els", length ? &sg : NULL, ZFCP_DBF_SAN_ELS,
+		     length, fsf->req_id, ntoh24(srb->d_id), length);
 }
 
 /**
-- 
2.53.0


             reply	other threads:[~2026-09-24 12:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-24 12:24 Ajaykumar Rajappa [this message]
2026-09-24 12:32 ` [PATCH v3] zfcp: Fix integer underflow in status read buffer payload length sashiko-bot
  -- strict thread matches above, loose matches on Subject: below --
2026-09-24 11:52 Ajaykumar Rajappa
2026-09-24 12:04 ` 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=20260924122400.1185067-1-ajaykr@linux.ibm.com \
    --to=ajaykr@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