CVE-2026-64102

What it actually does

This is a Linux kernel memory-corruption vulnerability in the Soft-iWARP RDMA driver (`RDMA/siw`). A remote connected iWARP peer can send a malformed MPA FPDU whose peer-controlled length field is smaller than the fixed DDP/RDMAP header length for the selected opcode. Because the driver previously failed to validate that minimum length before doing signed receive-length arithmetic, the calculated remaining FPDU length can become negative. That negative value can bypass memory-range checks and later be promoted to a very large unsigned copy length inside `skb_copy_bits()`, causing an out-of-bounds or use-after-free kernel memory read. In practical terms, exploitation can crash the kernel and may expose or corrupt kernel memory depending on build, configuration, and runtime conditions.

Why it matters to the business

Systems using Linux Soft-iWARP/RDMA over TCP can be remotely destabilized by a malicious peer, potentially causing kernel crashes, service outages, and disruption of workloads that rely on RDMA networking. Because the flaw is in kernel networking code and has a network attack vector with no authentication or user interaction required, exposed RDMA-capable systems should be treated as high priority even though EPSS is currently low and no known KEV listing or ransomware use is reported.

How an attack unfolds

An attacker first needs network-level access to establish or interact with an iWARP/Soft-iWARP connection to a vulnerable Linux system. After the connection is active, the attacker sends a deliberately malformed MPA FPDU with an opcode that implies a fixed DDP/RDMAP header length, but with an MPA length field smaller than the protocol minimum for that opcode. The vulnerable kernel parses the full header, then subtracts the larger header length from the smaller peer-supplied length, producing a negative remaining-length value. That negative value is reused as a copy length and memory-validation input; the validation can incorrectly succeed, and the copy path can convert the signed negative length into a very large unsigned size. The resulting kernel memory access can trigger a crash, KASAN report, use-after-free read, or other memory-corruption symptoms. Successful exploitation does not require local credentials or user interaction, but it does require the vulnerable Soft-iWARP code path to be enabled and reachable.

How to fix it

Apply a Linux kernel update that includes the RDMA/siw fix validating the MPA FPDU length before signed receive-length arithmetic. No exact fixed package versions were provided in the input, so use the security advisory for the specific Linux distribution, vendor kernel, or upstream stable branch in use. If immediate patching is not possible, reduce exposure by disabling Soft-iWARP/RDMA where not required, unloading or blocking the `siw` kernel module if operationally safe, restricting RDMA/iWARP connectivity to trusted peers only, and enforcing network controls that prevent untrusted hosts from initiating RDMA-related TCP connections. Treat mitigations as temporary because the affected code is in kernel space.

How to confirm the fix worked

Confirm that the running kernel includes the fix that rejects MPA FPDUs where the peer-supplied MPA length is less than the opcode-specific minimum header length. Validate by checking the installed kernel package against the vendor’s fixed advisory, confirming the running kernel after reboot with standard OS inventory commands, and verifying whether the `siw` module is loaded or Soft-iWARP interfaces are configured. Where safe in a test environment, a negative test can attempt to deliver malformed FPDUs and confirm the connection is terminated with an MPA framing error rather than causing kernel warnings, KASAN findings, or crashes. Also confirm that network access to RDMA/iWARP listeners is restricted to expected trusted sources.

Typical attack path

1. Identify Linux systems exposing Soft-iWARP/iWARP RDMA over TCP or services that allow RDMA connection establishment.
2. Establish a TCP/RDMA connection as a malicious peer.
3. Send a crafted MPA FPDU with an opcode such as tagged WRITE or read response and an MPA length smaller than the required DDP/RDMAP header length.
4. Trigger signed integer underflow in the kernel receive path when the driver computes the remaining FPDU length.
5. Cause the negative length to pass into memory validation and then into socket-buffer copy logic as a very large unsigned length.
6. Induce kernel memory read corruption, kernel warning/oops, or full system crash.

How to detect it

To determine whether exploitation may already have occurred, review kernel logs, system journals, crash dumps, and monitoring alerts for kernel oops, panic, KASAN, or call traces involving the Soft-iWARP receive path. Useful log sources include `dmesg`, `/var/log/kern.log`, `/var/log/messages`, `journalctl -k`, kernel crash dump repositories, EDR telemetry for kernel panics/reboots, and network telemetry for unusual RDMA/iWARP TCP sessions. Look for traces that include `skb_copy_bits`, `siw_rx_kva`, `siw_rx_umem`, `siw_rx_data`, `siw_check_mem`, `siw_proc_write`, `siw_proc_rresp`, `siw_tcp_rx_data`, `__tcp_read_sock`, or `siw_qp_llp_data_ready`. In packet captures, look for iWARP MPA FPDUs where the MPA length field is smaller than the fixed header length required by the opcode; such packets should be treated as suspicious when observed from unexpected peers. Because exploitation may only produce a crash or transient kernel memory fault, absence of durable file artifacts does not prove non-exploitation.

• BUG: KASAN: use-after-free in skb_copy_bits
• Read of size 4294967295
• skb_copy_bits
• siw_rx_kva
• siw_rx_umem
• siw_rx_data
• siw_check_mem
• siw_proc_write
• siw_proc_rresp
• siw_tcp_rx_data
• __tcp_read_sock
• siw_qp_llp_data_ready
• tcp_read_sock
• tcp_data_ready
• tcp_data_queue
• TERM_ERROR_LAYER_LLP
• LLP_ETYPE_MPA
• LLP_ECODE_FPDU_START
• Marker and ULPDU Length fields do not agree on the start of an FPDU
• siw

What your security team should do

• Prioritize patching Linux systems that have Soft-iWARP/RDMA enabled or that expose RDMA over TCP to networks outside a tightly trusted boundary.
• Inventory systems for loaded or available `siw` kernel modules and active RDMA/iWARP configuration.
• If patching is delayed, disable Soft-iWARP where unused or restrict RDMA/iWARP network paths to trusted peer IP ranges only.
• Monitor kernel logs for `skb_copy_bits`, `siw_tcp_rx_data`, `siw_proc_write`, `siw_rx_kva`, and related crash traces.
• Review network telemetry for unexpected RDMA/iWARP connection attempts or malformed MPA traffic from untrusted systems.
• Track vendor kernel advisories because fixed versions are distribution-specific and were not provided with this record.
• Do not rely on the low current EPSS score as a reason to defer remediation on exposed RDMA systems; the CVSS impact is critical and the bug is reachable remotely when the vulnerable path is exposed.