From: Alexandru Hossu <hossu.alexandru@gmail.com>
To: Hannes Reinecke <hare@suse.com>
Cc: David Disseldorp <ddiss@suse.de>,
martin.petersen@oracle.com, bvanassche@acm.org,
mlombard@arkamax.eu, target-devel@vger.kernel.org,
linux-scsi@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH v3] scsi: target: iscsi: validate CHAP_R length before base64 decode
Date: Fri, 22 May 2026 03:37:41 -0700 (PDT) [thread overview]
Message-ID: <6a1031f5.e5f1cd4d.398bf4.edc9@mx.google.com> (raw)
In-Reply-To: <430612f0-53f6-49bc-acd5-e69df3b330da@suse.com>
On Fri, May 22, 2026, Hannes Reinecke wrote:
> The length check should be part of the chap_base64_decode() function,
> which should reject inputs with the wrong length. _And_ you need
> to add a 'length' argument for 'client_digest' such that the function
> knows the size of the output buffer and can avoid precisely these
> issues.
Thank you for the feedback. Adding a dst_len parameter to
chap_base64_decode() and moving the overflow check inside the decoder
is a cleaner approach and I agree it is the right direction.
v4 carries David's Reviewed-by and fixes the immediate overflow with a
minimal diff. Would it be acceptable to merge v4 as a quick fix for the
overflow, with a follow-up patch that adds the dst_len parameter to
chap_base64_decode() and removes the pre-check?
Alexandru
prev parent reply other threads:[~2026-05-22 10:37 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-18 12:18 [PATCH] scsi: target: iscsi: validate CHAP_R length before base64 decode Alexandru Hossu
2026-05-18 14:40 ` David Disseldorp
2026-05-18 23:50 ` [PATCH v2] " Alexandru Hossu
2026-05-20 15:56 ` Maurizio Lombardi
2026-05-20 16:53 ` Alexandru Hossu
2026-05-20 18:02 ` Dmitry Bogdanov
2026-05-21 0:43 ` Alexandru Hossu
2026-05-22 9:53 ` Hannes Reinecke
2026-05-18 23:51 ` [PATCH] " Alexandru Hossu
2026-05-20 16:52 ` [PATCH v3] " Alexandru Hossu
2026-05-21 14:38 ` David Disseldorp
2026-05-22 9:56 ` Hannes Reinecke
2026-05-22 10:37 ` Alexandru Hossu [this message]
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=6a1031f5.e5f1cd4d.398bf4.edc9@mx.google.com \
--to=hossu.alexandru@gmail.com \
--cc=bvanassche@acm.org \
--cc=ddiss@suse.de \
--cc=hare@suse.com \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=mlombard@arkamax.eu \
--cc=stable@vger.kernel.org \
--cc=target-devel@vger.kernel.org \
/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.