CVE-2026-63888

What it actually does

This is a remotely reachable memory-corruption flaw in the Linux kernel LIO iSCSI target Text PDU handling path. When an iSCSI initiator negotiates DataDigest=CRC32C, the kernel can calculate a CRC over four bytes beyond the allocated Text payload buffer, causing an out-of-bounds kernel read. A separate error path for bad DataDigest handling with ErrorRecoveryLevel greater than 0 frees the Text buffer without clearing the saved pointer, allowing the same pointer to be freed again during a subsequent Text request or session teardown. On hardened kernels this is likely to trigger a remote kernel BUG or panic; on less-hardened kernels it may corrupt slab allocator metadata and could potentially affect confidentiality, integrity, and availability.

Why it matters to the business

Systems exposing the Linux kernel iSCSI target service may be remotely crashed or destabilized by unauthenticated network traffic, causing storage service interruption for dependent hosts and applications. Because the issue is network reachable with low attack complexity and has a CVSS score of 9.8, it should be treated as high priority for any environment using Linux as an iSCSI target, even though EPSS is currently low, exploit maturity is listed as none, and it is not currently in the CISA Known Exploited Vulnerabilities catalog.

How an attack unfolds

An attacker connects to a Linux iSCSI target and negotiates session parameters that enable DataDigest using CRC32C. The attacker then sends Text-phase iSCSI PDUs that cause the target to process a Text payload and compute a digest using an incorrect buffer length, leading the kernel to read past the allocated buffer. To trigger the double-free path, the attacker uses a bad DataDigest while ErrorRecoveryLevel is greater than 0, causing the target to drop the PDU and free the associated Text buffer while leaving a stale pointer behind. A later Text request using the same task tag, or a session teardown, causes the kernel to free the stale pointer again. The most likely observable outcome is a kernel warning, BUG, panic, iSCSI target failure, or host crash; under weaker allocator hardening, memory corruption may be possible.

How to fix it

Upgrade the Linux kernel to a version that includes the upstream fixes for the LIO iSCSI target Text PDU handling bugs. Because no product-specific fixed versions were provided, use distribution vendor advisories or upstream stable kernel release notes to identify the first patched kernel for each platform. If immediate patching is not possible, reduce exposure by disabling the Linux iSCSI target service where it is not required, restricting access to trusted initiator IP addresses only, blocking untrusted access to TCP port 3260, and reviewing whether DataDigest=CRC32C and ErrorRecoveryLevel greater than 0 are enabled or accepted. These mitigations reduce risk but should not be treated as a substitute for applying the kernel fix.

How to confirm the fix worked

Confirm the running kernel includes the fix, not only that a patched package is installed. Validate with uname, package manager metadata, vendor advisory mapping, or source review. In source, the CRC calculation should use the actual padded payload length rather than the DataDigest-extended receive length, and the ERL>0 bad DataDigest free path should clear cmd->text_in_ptr after freeing it. Confirm whether the host is exposing the iSCSI target service by checking for targetcli/LIO configuration, kernel target modules, and listeners on TCP port 3260. After patching and rebooting into the fixed kernel, monitor kernel logs during normal iSCSI Text negotiation for absence of KASAN, double-free, slab, or kernel BUG messages associated with iscsit_handle_text_cmd, iscsit_setup_text_cmd, iscsit_release_cmd, or crc32c.

Typical attack path

1. Identify a host exposing the Linux iSCSI target service, commonly on TCP port 3260.
2. Establish an iSCSI session as an initiator and negotiate DataDigest=CRC32C.
3. Send a Text Request PDU that causes the target to process a digested Text payload, triggering the CRC out-of-bounds read path.
4. If attempting the double-free condition, send a Text Request with an invalid DataDigest while ErrorRecoveryLevel is greater than 0.
5. Send another Text Request using the same ITT or force session teardown so the stale Text buffer pointer is freed again.
6. Observe service disruption, kernel BUG output, target reset, or host crash.

How to detect it

To determine whether exploitation may already have occurred, review kernel logs, system journals, crash dumps, and storage service monitoring for evidence of iSCSI target crashes or memory-corruption diagnostics. Useful sources include dmesg output, journalctl -k, /var/log/kern.log, /var/log/messages, vmcore/kdump artifacts, iSCSI target service logs, network flow logs for TCP/3260, and IDS telemetry showing unusual iSCSI Text Request activity. Look for KASAN reports showing slab-out-of-bounds reads in crc32c or iscsit_handle_text_cmd, double-free reports in iscsit_setup_text_cmd or iscsit_release_cmd, kernel BUG or panic messages near iSCSI target activity, unexpected target resets, repeated iSCSI session reconnects, DataDigest mismatch messages, and traffic from unfamiliar initiators. There are no reliable payload-level IOCs from the advisory alone, so detection should focus on crash artifacts, kernel allocator diagnostics, and anomalous iSCSI access patterns.

• TCP/3260
• iscsit_handle_text_cmd
• iscsit_setup_text_cmd
• iscsit_release_cmd
• crc32c
• BUG: KASAN: slab-out-of-bounds
• BUG: KASAN: double-free
• KASAN: double-free in iscsit_setup_text_cmd
• KASAN: double-free in iscsit_release_cmd
• slab-out-of-bounds in crc32c
• kernel BUG
• DataDigest
• DataDigest=CRC32C
• ErrorRecoveryLevel
• CmdSN gap
• Text Request
• Text PDU
• iSCSI target
• target_core_mod
• iscsi_target_mod

What your security team should do

• Inventory Linux systems running the LIO iSCSI target service and prioritize any internet-exposed or broadly reachable storage targets.
• Patch affected kernels through the operating system vendor and reboot into the fixed kernel as soon as operationally feasible.
• Until patched, restrict TCP/3260 to trusted initiators and storage networks; block all untrusted access at firewalls and security groups.
• Review iSCSI target configuration for DataDigest and ErrorRecoveryLevel settings and reduce risky negotiation options where compatible with operational requirements.
• Search historical kernel logs, crash dumps, and monitoring alerts for signs of slab out-of-bounds reads, double-free events, kernel BUGs, or unexpected reboots involving the iSCSI target code path.
• Ensure crash dump collection is enabled on critical storage hosts so any future kernel panic can be triaged.
• Because this is not currently KEV-listed and EPSS is low, prioritize based on exposure: public or multi-tenant storage networks first, isolated and unused target systems later.