All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Ajaykumar Rajappa" <ajaykr@linux.ibm.com>
Cc: "Vasily Gorbik" <gor@linux.ibm.com>,
	"Alexander Gordeev" <agordeev@linux.ibm.com>,
	linux-s390@vger.kernel.org,
	"Christian Borntraeger" <borntraeger@linux.ibm.com>,
	"Heiko Carstens" <hca@linux.ibm.com>
Subject: Re: [PATCH v3] zfcp: Fix integer underflow in status read buffer payload length
Date: Thu, 24 Sep 2026 12:32:25 +0000	[thread overview]
Message-ID: <20260924123226.36A161F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260924122400.1185067-1-ajaykr@linux.ibm.com>

> 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>

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

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


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

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-24 12:24 [PATCH v3] zfcp: Fix integer underflow in status read buffer payload length Ajaykumar Rajappa
2026-09-24 12:32 ` sashiko-bot [this message]
  -- 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=20260924123226.36A161F000FF@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.