Linux: Out-of-bounds Write
CVE-2026-63886 is a critical-severity out-of-bounds write vulnerability in Linux, with a CVSS 3.1 base score of 9.8 out of 10. It can be exploited remotely over the network by an unauthenticated attacker, without any action from a user. The record lists versions 82454e6f21e56ea9a0a9de7d0ff7e1dfb83e34d6, edd06675a02376ea8347dba7c29ad982ba5b36ee, bf154c657828ed05399bca5d98cf1611bb048b12 as the first without the flaw, so updating Linux to one of those releases or later removes the exposure. There is no confirmed exploitation so far. EPSS estimates a 0.71% chance of exploitation within 30 days, higher than 54% of scored CVEs.
Critical severity: a successful attack would have severe impact.
What to do
- Update Linux to 82454e6f21e56ea9a0a9de7d0ff7e1dfb83e34d6 or edd06675a02376ea8347dba7c29ad982ba5b36ee or bf154c657828ed05399bca5d98cf1611bb048b12 or 4a3a19c98a8207ad08bec554703d90f2c34a8cc6, whichever matches your release line, or a later version.
- Update Linux Kernel to 6.1.176 or 6.6.143 or 6.12.93 or 6.18.35, whichever matches your release line, or a later version.
- Until you can update, restrict network access to the affected service so it is not reachable from untrusted networks.
Affected products and versions
| Vendor | Product | Affected versions | Fixed in |
|---|---|---|---|
| Linux | Linux | 1e5733883421495908f3b90d9d807663038b4136 up to, but not including, 82454e6f21e56ea9a0a9de7d0ff7e1dfb83e34d6; 1e5733883421495908f3b90d9d807663038b4136 up to, but not including, edd06675a02376ea8347dba7c29ad982ba5b36ee; 1e5733883421495908f3b90d9d807663038b4136 up to, but not including, bf154c657828ed05399bca5d98cf1611bb048b12; 1e5733883421495908f3b90d9d807663038b4136 up to, but not including, 4a3a19c98a8207ad08bec554703d90f2c34a8cc6; 1e5733883421495908f3b90d9d807663038b4136 up to, but not including, c04e85799356120209b351a148ac2db888d5ffd9; 1e5733883421495908f3b90d9d807663038b4136 up to, but not including, 85db7391310b1304d2dc8ae3b0b12105a9567147; 6.0 | 82454e6f21e56ea9a0a9de7d0ff7e1dfb83e34d6, edd06675a02376ea8347dba7c29ad982ba5b36ee, bf154c657828ed05399bca5d98cf1611bb048b12, 4a3a19c98a8207ad08bec554703d90f2c34a8cc6, c04e85799356120209b351a148ac2db888d5ffd9, 85db7391310b1304d2dc8ae3b0b12105a9567147 |
| Linux | Linux Kernel | 6.0 up to, but not including, 6.1.176; 6.2 up to, but not including, 6.6.143; 6.7 up to, but not including, 6.12.93; 6.13 up to, but not including, 6.18.35; 6.19 up to, but not including, 7.0.12; 7.1 | 6.1.176, 6.6.143, 6.12.93, 6.18.35, 7.0.12 |
Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.
How the severity score breaks down
- Attack vector
- NetworkCan be exploited remotely over a network, including the internet.
- Attack complexity
- LowNo special conditions are needed; the attack works reliably.
- Privileges required
- NoneNo account or login is needed.
- User interaction
- NoneNo action by a victim is required.
- Scope
- UnchangedImpact stays within the vulnerable component.
- Confidentiality
- HighAll data handled by the component can be read.
- Integrity
- HighData or code can be modified at will.
- Availability
- HighThe component can be taken down completely.
Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Scored by CNA.
Official 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.
Source: the CVE record as published by its numbering authority, via NVD and CVE.org.
The underlying weakness: Out-of-bounds Write
The product writes data past the end, or before the beginning, of the intended buffer.
How developers prevent this class of flaw
- Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, many languages that perform their own memory management, such as Java and Perl, are not subject to buffer overflows. Other languages, such as Ada and C#, typically provide overflow protection, but the protection can be disabled by the programmer. Be wary that a language's interface to native code may still be subject to overflows, even if the language itself is theoretically safe.
- Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. Examples include the Safe C String Library (SafeStr) by Messier and Viega, and the Strsafe.h library from Microsoft. These libraries provide safer versions of overflow-prone string-handling functions.
- Use automatic buffer overflow detection mechanisms that are offered by certain compilers or compiler extensions. Examples include: the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice, which provide various mechanisms including canary-based detection and range/index checking. D3-SFCV (Stack Frame Canary Validation) from D3FEND discusses canary-based detection in detail.
Timeline
- CVE record published.
- CISA published its SSVC assessment (exploitation: none, automatable: yes, technical impact: total).
- Record last changed materially (score, affected products, status or references).
References
Patches and release notes
- git.kernel.org/stable/c/4a3a19c98a8207ad08bec554703d90f2c34a8cc6
- git.kernel.org/stable/c/82454e6f21e56ea9a0a9de7d0ff7e1dfb83e34d6
- git.kernel.org/stable/c/85db7391310b1304d2dc8ae3b0b12105a9567147
- git.kernel.org/stable/c/bf154c657828ed05399bca5d98cf1611bb048b12
- git.kernel.org/stable/c/c04e85799356120209b351a148ac2db888d5ffd9
- git.kernel.org/stable/c/edd06675a02376ea8347dba7c29ad982ba5b36ee
Recent Out-of-bounds Write vulnerabilities
- 7.8 High severity
- 7.8 High severity
- 7.8 High severity
- 7.8 High severity
- 8.4 High severity
- 7.8 High severity
Spotted an error? Tell us.