Skip to main content
VulnerabilityPublished

CVE-2026-63886: Linux kernel · scsi: target: iscsi: Validate CHAP_R length before base64 decode

Source GCVE Database

0
Authoritative record:CVE-2026-63886· Critical 9.8

Not known to be exploited · CVSS 9.8 Critical · fixed in edd06675a02376ea8347dba7c29ad982ba5b36ee : patch Linux kernel as a priority.

Data as of 26 Oct 2026, 13:47 UTC

CVSS 3.1 base score
9.8Critical
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.7% chance of exploitation in 30 days – higher than 53% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch
Available – fixed in edd06675a02376ea8347dba7c29ad982ba5b36ee, c04e85799356120209b351a148ac2db888d5ffd9, bf154c657828ed05399bca5d98cf1611bb048b12 +3
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 19 Jul 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade to a fixed release listed under Affected software.

Affected software

ProductAffectedFixed in
LinuxLinuxAffected
  • ≥ 1e5733883421495908f3b90d9d807663038b4136, < edd06675a02376ea8347dba7c29ad982ba5b36ee
Fixed in
  • edd06675a02376ea8347dba7c29ad982ba5b36ee
LinuxLinuxAffected
  • ≥ 1e5733883421495908f3b90d9d807663038b4136, < c04e85799356120209b351a148ac2db888d5ffd9
Fixed in
  • c04e85799356120209b351a148ac2db888d5ffd9
LinuxLinuxAffected
  • ≥ 1e5733883421495908f3b90d9d807663038b4136, < bf154c657828ed05399bca5d98cf1611bb048b12
Fixed in
  • bf154c657828ed05399bca5d98cf1611bb048b12
LinuxLinuxAffected
  • ≥ 1e5733883421495908f3b90d9d807663038b4136, < 82454e6f21e56ea9a0a9de7d0ff7e1dfb83e34d6
Fixed in
  • 82454e6f21e56ea9a0a9de7d0ff7e1dfb83e34d6
LinuxLinuxAffected
  • ≥ 1e5733883421495908f3b90d9d807663038b4136, < 85db7391310b1304d2dc8ae3b0b12105a9567147
Fixed in
  • 85db7391310b1304d2dc8ae3b0b12105a9567147
LinuxLinuxAffected
  • ≥ 1e5733883421495908f3b90d9d807663038b4136, < 4a3a19c98a8207ad08bec554703d90f2c34a8cc6
Fixed in
  • 4a3a19c98a8207ad08bec554703d90f2c34a8cc6

AI-suggested

If you cannot patch yet, avoid exposing the vulnerable iSCSI target service to untrusted networks or inputs.

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.

References

Community reviews

Loading reviews…