All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Ajaykumar Rajappa" <ajaykr@linux.ibm.com>
Cc: "Christian Borntraeger" <borntraeger@linux.ibm.com>,
	linux-s390@vger.kernel.org,
	"Alexander Gordeev" <agordeev@linux.ibm.com>,
	"Vasily Gorbik" <gor@linux.ibm.com>,
	"Heiko Carstens" <hca@linux.ibm.com>
Subject: Re: [PATCH v4] zfcp: Fix integer underflow in status read buffer payload length
Date: Mon, 05 Oct 2026 09:55:59 +0000	[thread overview]
Message-ID: <20261005095559.BAED81F0089F@smtp.kernel.org> (raw)
In-Reply-To: <20261005094631.3361197-1-ajaykr@linux.ibm.com>

> 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 srb->length before subtracting the payload
> offset. If the reported buffer length does not reach the payload area,
> prevent payload access and treat the payload as empty.
> 
> For SAN tracing, retain the original channel-reported SRB length in the
> trace record when no valid payload area exists. This preserves trace
> evidence of anomalous firmware-reported lengths for serviceability,
> while using a capture length of zero to ensure that no payload data is
> accessed 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>

Sashiko has reviewed this patch and found no issues. It looks great!

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


  reply	other threads:[~2026-10-05  9:56 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-05  9:46 [PATCH v4] zfcp: Fix integer underflow in status read buffer payload length Ajaykumar Rajappa
2026-10-05  9:55 ` sashiko-bot [this message]
  -- strict thread matches above, loose matches on Subject: below --
2026-10-05  9:23 Ajaykumar Rajappa
2026-10-05  9:33 ` 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=20261005095559.BAED81F0089F@smtp.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.