CVE-2026-63886 in Linux
Summary
by MITRE • 07/19/2026
In the Linux kernel, the following vulnerability has been resolved:
scsi: target: iscsi: Validate CHAP_R length before base64 decode
chap_server_compute_hash() allocates client_digest as kzalloc(chap->digest_size) and then, for BASE64-encoded responses, passes chap_r directly to chap_base64_decode() without checking whether the input length could produce more than digest_size bytes of output.
chap_base64_decode() writes to the destination unconditionally as long as there is input to consume. With MAX_RESPONSE_LENGTH set to 128 and the "0b" prefix stripped by extract_param(), up to 127 base64 characters can reach the decoder. 127 characters decode to 95 bytes. For SHA-256 (digest_size=32) this overflows client_digest by 63 bytes; for MD5 (digest_size=16) the overflow is 79 bytes.
The length check at line 344 fires after the write has already happened.
The HEX branch in the same switch statement already validates the length up front. Apply the same approach to the BASE64 branch: strip trailing base64 padding characters, then reject any input whose data length exceeds DIV_ROUND_UP(digest_size * 4, 3) before calling the decoder.
Stripping trailing '=' before the comparison handles both padded and unpadded encodings. chap_base64_decode() already returns early on '=', so the full original string is still passed to the decoder unchanged.
The mutual CHAP path decodes CHAP_C into initiatorchg_binhex, which is kzalloc(CHAP_CHALLENGE_STR_LEN). extract_param() caps initiatorchg at CHAP_CHALLENGE_STR_LEN characters, so at most CHAP_CHALLENGE_STR_LEN-1 base64 characters reach the decoder. The maximum decoded size, DIV_ROUND_UP((CHAP_CHALLENGE_STR_LEN-1) * 3, 4), is less than CHAP_CHALLENGE_STR_LEN, so no overflow is possible there. A comment is added at the call site to document this.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 07/19/2026
The vulnerability resides within the Linux kernel's iSCSI target implementation where improper validation of CHAP_R parameter length before base64 decoding leads to a buffer overflow condition. This issue affects the chap_server_compute_hash() function which dynamically allocates memory for client_digest based on digest_size but fails to validate that incoming base64-encoded data will not exceed the allocated buffer boundaries. The flaw occurs because the function processes base64 input without first ensuring that the decoded output length will fit within the pre-allocated memory space. According to the ATT&CK framework, this represents a code injection technique through buffer overflow manipulation under the T1055 category of Process Injection. The vulnerability specifically targets the CHAP authentication mechanism used in iSCSI protocol implementations where security credentials are exchanged between initiators and targets during connection establishment.
The technical execution path begins with the allocation of client_digest memory using kzalloc(chap->digest_size) which creates a buffer sized exactly for the expected digest output. However, when processing BASE64-encoded responses, the code directly passes chap_r to chap_base64_decode() without validating that the input length could produce more than digest_size bytes of decoded output. The MAX_RESPONSE_LENGTH constant set to 128 characters allows up to 127 base64 characters to reach the decoder after stripping the "0b" prefix through extract_param(). Through mathematical calculation, 127 base64 characters decode to 95 bytes which significantly exceeds the buffer boundaries for both SHA-256 (32 bytes) and MD5 (16 bytes) digest algorithms. This represents a classic buffer overflow scenario where memory corruption occurs due to lack of proper bounds checking before data processing. The CWE classification for this vulnerability aligns with CWE-121 which describes stack-based buffer overflow conditions in software systems.
The operational impact of this vulnerability extends beyond simple memory corruption as it creates potential attack vectors for privilege escalation and system compromise within iSCSI target environments. An attacker could exploit this flaw by crafting malicious CHAP_R parameters that cause the kernel to write beyond allocated memory boundaries, potentially leading to denial of service conditions or more severe consequences including code execution in kernel space. The vulnerability affects systems running Linux kernels with iSCSI target functionality where CHAP authentication is enabled and used for security. In enterprise environments utilizing iSCSI storage networks, this flaw could allow unauthorized users to disrupt storage services or gain elevated privileges within the storage subsystem. The issue particularly impacts organizations using iSCSI targets for critical storage infrastructure where maintaining system integrity and availability is paramount.
The mitigation strategy involves implementing length validation consistent with existing code patterns within the same function. The solution requires adding a pre-validation check that strips trailing base64 padding characters before comparing input length against the maximum allowable decoded size calculated as DIV_ROUND_UP(digest_size * 4, 3). This approach mirrors the already implemented HEX branch validation logic which properly validates length upfront before processing. The fix ensures that only appropriately sized base64 inputs proceed to the decoder function while maintaining backward compatibility with both padded and unpadded base64 encodings. Additionally, a comment has been added at the call site for the mutual CHAP path to document why no overflow is possible in that specific code path where CHAP_C is decoded into initiatorchg_binhex using kzalloc(CHAP_CHALLENGE_STR_LEN) with proper bounds checking through extract_param() limiting input to CHAP_CHALLENGE_STR_LEN characters. This defensive programming approach prevents similar issues from occurring in other parts of the codebase and follows established security practices for buffer management and input validation within kernel space operations.