A mutual CHAP handshake requires target processing of an initiator-sent
CHAP_I identifier. The RFC 3720 specification states:
11.1.4. Challenge Handshake Authentication Protocol (CHAP)
...
CHAP_A=<A> CHAP_I=<I> CHAP_C=<C>
...
Where N, (A,A1,A2), I, C, and R are (correspondingly) the Name,
Algorithm, Identifier, Challenge, and Response as defined in
[RFC1994], N is a text string, A,A1,A2, and I are numbers
CHAP_I parsing currently calls extract_param(), which returns the
@identifier string (stripped of any 0b/0B or 0x/0X prefix) and a @type
which indicates DECIMAL, HEX, or BASE64 encoding (based on any stripped
prefix).
Any HEX encoded CHAP_I string is further processed via:
ret = kstrtoul(&identifier[2], 0, &id);
This is incorrect for two reasons:
* The @identifier string has already been stripped of the 0x/0X prefix,
so skipping the first two bytes omits part of the number.
* The kstrtoul() call specifies a base of 0, which will see
&identifier[2] parsed as a decimal, unless a '0x' or (octal) '0' is
erroneously present at that offset.
Fix this by passing the (zero-offset) identifier string to kstrtoul()
along with a base=16 parameter. Also add an explicit error handler for
BASE64 encoding.
Hex-encoded CHAP_I handling can be testing using the libiscsi EncodedI
test linked below.
Reported-by: Sashiko (gemini/gemini-3.1-pro-preview)
Link: https://sashiko.dev/#/patchset/20260521151121.808477-1-hossu.alexandru%40gmail.com
Link: https://github.com/sahlberg/libiscsi/pull/473
Fixes: 85db7391310b ("scsi: target: iscsi: Validate CHAP_R length before base64 decode")
Signed-off-by: David Disseldorp <ddiss@suse.de>
Reviewed-by: Lee Duncan <lduncan@suse.com>
Reviewed-by: John Garry <john.g.garry@oracle.com>
Link: https://patch.msgid.link/20260605122019.24146-2-ddiss@suse.de
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>