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 v5] zfcp: Fix integer underflow in status read buffer payload length
Date: Thu, 8 Oct 2026 11:57:57 +0200 [thread overview]
Message-ID: <20261008095757.1813357-1-ajaykr@linux.ibm.com> (raw)
zfcp_dbf_hba_fsf_uss() only guards against a zero-length status read
buffer. If srb->length is smaller than the fixed header size of
struct fsf_status_read_buffer, subtracting the payload offset
underflows and can lead to an out-of-bounds read.
zfcp_dbf_san_in_els() has the same issue, where the underflowed value
is used as the scatterlist payload length.
Fix both cases by validating payload access against the payload offset.
If the reported buffer length does not reach the payload area, suppress
payload reads and avoid constructing a scatterlist for non-existent
payload data.
For HBA tracing, preserve serviceability by unconditionally storing the
value-shifted SRB length in pl_len. This retains a reversible mapping to
the original channel-reported length without changing the existing trace
record format, while payload data is only read when the reported buffer
length reaches the payload area.
For SAN tracing, preserve the original channel-reported SRB length in
the trace record and separately track the number of payload bytes that
may be safely read. This retains trace evidence of anomalous
firmware-reported lengths while preventing payload reads beyond the
reported buffer.
For valid payloads, preserve the existing tracing behavior.
Fixes: a54ca0f62f95 ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.")
Fixes: 2c55b750a884 ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.")
Signed-off-by: Ajaykumar Rajappa <ajaykr@linux.ibm.com>
---
Changes in v5:
- Address Steffen's review comments regarding HBA/SAN trace servicability.
- Preserve HBA pl_len semantics so trace readers can always assume the
value-shifted subtraction.
- Retain the original channel-reported SRB length in SAN trace records.
- Use a separate capped length to control payload reads in the SAN path.
- Prevent payload reads when the reported buffer length does not reach
the payload area.
Changes in v4:
- Preserve the original channel-reported SRB length in SAN trace
records when no payload area exists.
- Distinguish between the recorded length and the payload length that
may be accessed using length/cap_length semantics.
- Use a capture length of zero to prevent payload access for malformed
status read buffers.
- Address both the underflow/OOB issue and the trace serviceability
concern in the same patch.
Changes in v3:
- Rework payload length handling for srb->length < pay_offset and
treat such cases as an empty payload.
- Prevent payload processing and scatterlist initialization when the
reported buffer length does not reach the payload area.
- Keep the fix focused on the underflow/OOB issue and preserve the
existing tracing behavior for valid payloads.
Changes in v2:
- Preserve anomalous short srb->length values by capping payload lengths
to srb->length instead of forcing them to 0.
- Introduce a local pay_offs₹et variable to avoid repeated offsetof()
Changes on the git hub can be found at:
https://github.ibm.com/Ajay-Kumar-K-R/linux/tree/zfcp-fix-srb-length-underflow-v5
---
drivers/s390/scsi/zfcp_dbf.c | 38 +++++++++++++++++++++++++-----------
1 file changed, 27 insertions(+), 11 deletions(-)
diff --git a/drivers/s390/scsi/zfcp_dbf.c b/drivers/s390/scsi/zfcp_dbf.c
index 81fb8af408e9..c5501eae9977 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;
@@ -253,13 +254,17 @@ 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);
+ /* Unconditionally store value-shifted SRB length: pl_len is a bijective
+ * map of srb->length (pl_len + pay_offset == srb->length). A bogus
+ * srb->length < pay_offset wraps to a large non-zero pl_len, which is
+ * unambiguously distinguishable from pl_len == 0(genuine empty payload)
+ */
+ rec->pl_len = (u16)(srb->length - pay_offset);
- if (rec->pl_len)
+ /* Only access payload bytes when srb->length actually covers them. */
+ if (srb->length > pay_offset)
zfcp_dbf_pl_write(dbf, srb->payload.data, rec->pl_len,
- "fsf_uss", req->req_id, ZFCP_DBF_PAY_LEVEL);
+ "fsf_uss", req->req_id);
log:
debug_event(dbf->hba, level, rec, sizeof(*rec));
spin_unlock_irqrestore(&dbf->hba_lock, flags);
@@ -714,17 +719,28 @@ void zfcp_dbf_san_in_els(char *tag, struct zfcp_fsf_req *fsf)
struct zfcp_dbf *dbf = fsf->adapter->dbf;
struct fsf_status_read_buffer *srb =
(struct fsf_status_read_buffer *) fsf->data;
- u16 length;
+ u16 length, cap_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);
+ /*
+ * Store the original channel-reported SRB length in pl_len.
+ * cap_length specifies the number of payload bytes that may be read.
+ */
+ length = (u16)srb->length;
+ cap_length = 0;
+ if (srb->length > pay_offset) {
+ /* Payload present beyond the fixed header. */
+ cap_length = (u16)(srb->length - pay_offset);
+ sg_init_one(&sg, srb->payload.data, cap_length);
+ }
+
+ zfcp_dbf_san(tag, dbf, "san_els", cap_length ? &sg : NULL,
+ ZFCP_DBF_SAN_ELS, length, fsf->req_id,
+ ntoh24(srb->d_id), cap_length);
}
/**
--
2.53.0
next reply other threads:[~2026-10-08 9:58 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-08 9:57 Ajaykumar Rajappa [this message]
2026-10-08 10:08 ` [PATCH v5] zfcp: Fix integer underflow in status read buffer payload length sashiko-bot
-- strict thread matches above, loose matches on Subject: below --
2026-10-08 10:17 Ajaykumar Rajappa
2026-10-08 10:28 ` 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=20261008095757.1813357-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