CVE-2026-63886

What it actually does

This flaw is a remotely reachable kernel heap buffer overflow in the Linux kernel iSCSI target CHAP authentication path. When an iSCSI initiator sends a BASE64-encoded CHAP_R response, the kernel allocates a buffer sized to the expected digest length, such as 16 bytes for MD5 or 32 bytes for SHA-256, but decodes attacker-controlled BASE64 input into that buffer before validating that the decoded output will fit. An oversized CHAP_R value can therefore overwrite adjacent kernel heap memory. Because this occurs in kernel context and is reachable over the network during iSCSI login negotiation, the likely impacts are kernel crash, denial of service, memory corruption, and potentially kernel-level code execution depending on exploitability, configuration, allocator state, and mitigations.

Why it matters to the business

Systems exposing the Linux iSCSI target service can be crashed or potentially compromised remotely during authentication negotiation, creating risk of storage outages, data unavailability, host instability, and possible full system takeover. The CVSS severity is critical, but current public exploit maturity and EPSS are low, and it is not currently listed in CISA KEV; however, the vulnerability is only 22 days old, affects kernel-level storage infrastructure, and should be treated as high priority wherever iSCSI target services are reachable from untrusted or broadly accessible networks.

How an attack unfolds

An attacker first identifies a host exposing the Linux iSCSI target service, commonly over TCP port 3260. The attacker initiates an iSCSI login sequence and reaches CHAP authentication negotiation. Instead of supplying a correctly sized BASE64-encoded CHAP_R response, the attacker sends an oversized BASE64 value using the expected response format. The vulnerable kernel code strips the BASE64 prefix and passes the attacker-controlled input to the decoder before confirming that the decoded output fits in the allocated digest buffer. The decoder writes beyond the end of the heap allocation, corrupting adjacent kernel memory. Depending on memory layout and kernel hardening, this may immediately crash the kernel, trigger slab/KASAN corruption reports, destabilize the iSCSI target, or in a more advanced exploit path, allow controlled corruption that could lead to kernel-level execution.

How to fix it

Apply the Linux kernel update from the relevant distribution or kernel vendor that includes the fix for validating CHAP_R BASE64 length before decoding in the iSCSI target CHAP code. In source-based environments, confirm the patch equivalent to `scsi: target: iscsi: Validate CHAP_R length before base64 decode` is present. If immediate patching is not possible, reduce exposure by disabling the iSCSI target service where not required, blocking or tightly restricting TCP/3260 to trusted initiator networks, enforcing storage network segmentation, and preventing internet or broad internal access to target portals. Avoid relying on CHAP configuration changes alone as a mitigation; the safest compensating controls are patching and network access restriction.

How to confirm the fix worked

Confirm the running kernel version is at or above the vendor-fixed release for the deployed distribution, or verify that the kernel source/changelog contains the fix for pre-validating BASE64 CHAP_R length before `chap_base64_decode()` is called. Validate exposure by checking whether the host is listening for iSCSI target connections, especially on TCP/3260, and whether Linux LIO/kernel target configuration is active. Review `/sys/kernel/config/target/iscsi/`, `targetcli` output, loaded modules such as `iscsi_target_mod`, and firewall rules restricting access to target portals. After patching, confirm the updated kernel is actually booted, not merely installed. Where safe and authorized, use a non-destructive iSCSI login/authentication test to confirm malformed oversized CHAP_R authentication attempts are rejected without kernel warnings, service instability, or crash.

Typical attack path

1. Scan for systems exposing the Linux iSCSI target service, typically on TCP/3260.
2. Initiate an iSCSI login session to a reachable target portal.
3. Negotiate or trigger CHAP authentication handling.
4. Send a malformed BASE64-encoded CHAP_R response that decodes to more bytes than the expected CHAP digest size.
5. Cause the kernel iSCSI target code to decode the oversized response into an undersized heap buffer.
6. Leverage the resulting heap corruption to crash the host, disrupt storage services, or attempt further kernel exploitation.

How to detect it

To assess possible prior exploitation, review host and network telemetry around systems exposing Linux iSCSI target services. On hosts, examine `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, crash dumps, kdump/vmcore data, and hypervisor reset events for kernel oops, panic, slab corruption, KASAN reports, or general protection faults involving `iscsi_target_mod`, `iscsit`, `chap_base64_decode`, or `chap_server_compute_hash`. Look for sudden reboots or storage target outages preceded by iSCSI login activity. On the network side, inspect packet captures, Zeek/Suricata logs, firewall flow logs, or IDS metadata for iSCSI login negotiation sessions with CHAP authentication and abnormally long `CHAP_R` values. A suspicious pattern is a `CHAP_R` value beginning with the BASE64 marker `0b` where the BASE64 data length, after removing trailing `=`, exceeds the expected digest encoding size, especially more than 22 BASE64 characters for MD5 or more than 43 for SHA-256. Because successful exploitation may leave only crash artifacts and malformed authentication traffic, absence of application-level logs does not rule out exploitation.

• CHAP_R=0b
• CHAP_R=0b[A-Za-z0-9+/]{44,}={0,2}
• chap_base64_decode
• chap_server_compute_hash
• iscsi_target_mod
• iscsit
• BUG: KASAN: slab-out-of-bounds
• BUG: unable to handle kernel paging request
• kernel BUG at
• general protection fault
• slab-out-of-bounds
• use-after-free
• iSCSI Login Request
• SecurityNegotiation
• TCP/3260

What your security team should do

• Prioritize patching internet-exposed or broadly reachable Linux iSCSI target systems first, followed by storage networks with many initiators or weak segmentation.
• Inventory all systems running the Linux kernel iSCSI target/LIO service and identify listeners on TCP/3260.
• Restrict iSCSI target access to explicitly authorized initiator IPs or storage VLANs; block all other access at firewalls and host-based controls.
• Review recent kernel logs, system journals, and network telemetry for oversized CHAP_R authentication attempts or kernel memory corruption symptoms near iSCSI authentication handling.
• Ensure storage availability and recovery plans account for sudden iSCSI target host crashes, including multipath behavior and failover testing.
• Monitor vendor advisories for exact fixed kernel packages and deploy the fixed running kernel, followed by reboot validation.
• Add temporary IDS/SIEM detections for unusually long BASE64 CHAP_R values in iSCSI login negotiation traffic where packet inspection is available.