In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Validate CHAP_R length before base64 decode… (CVE-2026-63886)
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.
AI Analysis
Technical Summary
The Linux kernel's iSCSI target CHAP authentication code had a flaw where the length of the base64-encoded CHAP_R response was not validated before decoding. This allowed the base64 decoder to write beyond the allocated buffer size (client_digest), causing a buffer overflow. The vulnerability arises because the allocated buffer size is based on the digest size (e.g., 32 bytes for SHA-256), but up to 95 bytes could be decoded from the input, overflowing the buffer by up to 63 bytes. The fix applies a length check before decoding by stripping trailing '=' padding characters and rejecting inputs whose decoded length would exceed the buffer size. The HEX encoding branch already had this validation. The mutual CHAP path was not vulnerable due to stricter input length limits.
Potential Impact
This vulnerability could lead to a buffer overflow in the Linux kernel's iSCSI target CHAP authentication code. Buffer overflows in kernel code can potentially be exploited to cause denial of service or escalate privileges. However, no known exploits in the wild have been reported. The impact depends on the ability of an attacker to supply crafted CHAP_R responses to the vulnerable kernel component.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Until an official fix is applied, avoid exposing the vulnerable iSCSI target service to untrusted networks or inputs. Monitor vendor channels for updates and apply patches once available.
In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Validate CHAP_R length before base64 decode… (CVE-2026-63886)
Description
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.
CVSS v3.1
Score 9.8critical
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The Linux kernel's iSCSI target CHAP authentication code had a flaw where the length of the base64-encoded CHAP_R response was not validated before decoding. This allowed the base64 decoder to write beyond the allocated buffer size (client_digest), causing a buffer overflow. The vulnerability arises because the allocated buffer size is based on the digest size (e.g., 32 bytes for SHA-256), but up to 95 bytes could be decoded from the input, overflowing the buffer by up to 63 bytes. The fix applies a length check before decoding by stripping trailing '=' padding characters and rejecting inputs whose decoded length would exceed the buffer size. The HEX encoding branch already had this validation. The mutual CHAP path was not vulnerable due to stricter input length limits.
Potential Impact
This vulnerability could lead to a buffer overflow in the Linux kernel's iSCSI target CHAP authentication code. Buffer overflows in kernel code can potentially be exploited to cause denial of service or escalate privileges. However, no known exploits in the wild have been reported. The impact depends on the ability of an attacker to supply crafted CHAP_R responses to the vulnerable kernel component.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Until an official fix is applied, avoid exposing the vulnerable iSCSI target service to untrusted networks or inputs. Monitor vendor channels for updates and apply patches once available.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-f9cg-2c9v-xhmh
- Osv Schema Version
- 1.4.0
- Aliases
- ["CVE-2026-63886"]
- Ecosystems
- []
- Database Specific Severity
- null
- Cvss Version
- 3.1
Threat ID: 6a5d27ab2a4a8d598912fc8f
Added to database: 07/19/2026, 19:38:19 UTC
Last enriched: 07/19/2026, 20:11:45 UTC
Last updated: 08/28/2026, 10:52:09 UTC
Views: 64
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.