Re: [PATCH] scsi: target: iscsi: validate CHAP_R length before base64 decode
Alexandru Hossu <[email protected]> Mon, 18 May 2026 16:51:02 -0700 (PDT)
| Newsgroups | org.kernel.vger.target-devel,org.kernel.vger.linux-scsi,org.kernel.vger.stable |
|---|---|
| Message-ID | <[email protected]> |
On Mon, May 19, 2026, David Disseldorp <[email protected]> wrote: > nit: this could be DIV_ROUND_UP(chap->digest_size * 4, 3) to match > base64.h BASE64_CHARS(), right? Yes, equivalent and will use it in v2. > The above check doesn't appear to catch undersize base64 CHAP responses, > unlike the hex path. How does that affect the handshake? An undersize response decodes to fewer than digest_size bytes. chap_base64_decode() returns cp - dst, which is less than digest_size, so the existing != digest_size check at line 345 fires and the handshake fails. The result is the same as the hex path. > Finally, don't we need a similar check for the mutual CHAP code-path? The mutual path decodes CHAP_C into initiatorchg_binhex, allocated as kzalloc(CHAP_CHALLENGE_STR_LEN) = kzalloc(4096). extract_param() caps the input at CHAP_CHALLENGE_STR_LEN characters, so at most 4095 base64 chars reach the decoder, producing at most 3071 decoded bytes. 3071 < 4096, so the destination cannot overflow. The post-decode > 1024 check is a semantic limit on challenge size, not a safety net against overflow. v2 with DIV_ROUND_UP below. Alexandru