CVE-2026-53186

What it actually does

This is an improper input validation flaw in the Linux kernel RDMA SRP initiator path. When processing an SRP_RSP from an SRP target, the kernel uses the target-supplied resp_data_len value to calculate where SCSI sense data begins, but it does not verify that this offset is within the number of bytes actually received. A malicious or compromised SRP target that the initiator is already connected to can set SRP_RSP_FLAG_SNSVALID and provide an oversized resp_data_len, causing the initiator to read beyond the received RDMA buffer. The copied length is limited, but the source address is not, so the most likely impact is a kernel fault, panic, or crash of the affected Linux host. Exploitation requires access to or control of an SRP target on the relevant InfiniBand/RoCE fabric and an initiator that has logged into it.

Why it matters to the business

Successful exploitation can crash Linux systems that use RDMA SRP storage, causing application downtime, failed I/O, storage path disruption, or node eviction in clustered environments. The exposure is narrower than an internet-facing remote code execution issue because an attacker generally needs control of, or privileged access to, an SRP target reachable over the RDMA fabric. The vulnerability is not listed in CISA KEV, is not marked as ransomware-used, has low EPSS at 0.00514, and no exploit maturity is reported; however, systems relying on RDMA-backed storage should still prioritize patching because a storage-fabric crash can have high operational impact.

How an attack unfolds

An attacker first gains control of an SRP target or positions a malicious SRP target on an InfiniBand or RoCE fabric used by Linux initiators. The attacker waits for, induces, or already has an SRP login from a vulnerable Linux host. The malicious target then sends a crafted SRP_RSP message with the sense-valid flag set and a resp_data_len value that is much larger than the actual response length. The vulnerable ib_srp receive path calculates the sense-data source pointer using that untrusted value without confirming that the response data and sense region fit inside wc->byte_len. The kernel then attempts to copy up to the SCSI sense buffer size from an address beyond the received buffer. Depending on memory layout, this can trigger an out-of-bounds read fault and crash or panic the host, interrupting storage operations and workloads that depend on the affected system.

How to fix it

Apply a Linux kernel update that contains the RDMA/srp fix to bound SRP_RSP sense-data parsing by the received work-completion byte length. Because exact package fixed versions were not provided, use the fixed kernel builds from the relevant Linux distribution, appliance vendor, cloud image, or kernel stable branch once available. Reboot into the updated kernel after installation, as this is kernel code. Where immediate patching is not possible, reduce exposure by disabling the ib_srp module if SRP is not required, preventing untrusted SRP targets from being reachable, restricting RDMA fabric access to trusted storage endpoints, segmenting InfiniBand/RoCE networks, and monitoring for unexpected SRP logins or target changes. Do not rely on generic network perimeter controls if the affected hosts already trust the RDMA storage fabric.

How to confirm the fix worked

Confirm that affected systems are running a kernel build that includes the RDMA/srp change that only copies sense data when the SRP response header, response data, and sense region fit within the received byte length. Validate by checking the running kernel version after reboot, verifying distribution or vendor advisories for the specific package, and confirming that any live-patching or kernel module update actually covers ib_srp. Identify exposure by checking whether the ib_srp module is loaded or configured, whether SRP initiator tools are installed, and whether the host has active InfiniBand/RoCE SRP sessions. In mitigation scenarios, confirm that ib_srp cannot be loaded, SRP sessions are not active, and only approved SRP targets are reachable on the RDMA fabric.

Typical attack path

1. Gain control of a legitimate SRP target, compromise storage infrastructure, or introduce a malicious SRP target on the InfiniBand/RoCE fabric.
2. Ensure a vulnerable Linux SRP initiator logs into or remains connected to the attacker-controlled target.
3. Send an SRP_RSP response with SRP_RSP_FLAG_SNSVALID set.
4. Set resp_data_len to a value that places the calculated sense-data source outside the bytes actually received.
5. Cause the vulnerable kernel to perform an out-of-bounds read while copying sense data.
6. Trigger a kernel fault, panic, service crash, or storage-path failure on the affected host.

How to detect it

To determine whether exploitation may already have occurred, review kernel logs, system journals, crash dumps, kdump/vmcore artifacts, storage multipath logs, and RDMA fabric or SRP target logs for crashes or faults involving ib_srp, srp_process_rsp, SRP_RSP handling, SCSI sense data, or sudden SRP connection resets. Focus on events where a Linux host experienced a kernel oops, panic, general protection fault, page fault, or unexpected reboot shortly after SRP I/O errors or reconnects. Correlate affected host timelines with RDMA switch logs, fabric manager logs, storage target logs, and initiator login records to identify unexpected SRP targets or anomalous responses. Because the malformed SRP_RSP may not be preserved in normal logs, absence of a packet-level artifact does not rule out exploitation. If packet capture or RDMA telemetry is available, look for SRP_RSP messages with SRP_RSP_FLAG_SNSVALID and response-data lengths inconsistent with the received message size.

• srp_process_rsp
• ib_srp
• SRP_RSP_FLAG_SNSVALID
• general protection fault
• BUG: unable to handle page fault
• kernel panic
• Oops:
• Unable to handle kernel paging request
• workqueue: ib_srp
• RIP: srp_process_rsp
• Call Trace: srp_process_rsp
• SCSI sense
• SRP login
• SRP reconnect
• srp_daemon
• ibsrpdm

What your security team should do

• Inventory Linux systems using RDMA SRP, InfiniBand, or RoCE storage and prioritize them for kernel updates.
• Patch and reboot exposed systems using vendor kernel builds that include the RDMA/srp bounds-checking fix.
• Treat storage, RDMA, and fabric-management infrastructure as high-trust assets; investigate any unauthorized SRP target, fabric membership change, or unexpected initiator login.
• If SRP is not required, disable or blacklist ib_srp and remove unused SRP initiator configuration.
• Segment RDMA storage fabrics so only approved initiators and targets can communicate.
• Review kernel logs and crash dumps for ib_srp or srp_process_rsp faults, especially after storage errors or SRP reconnect events.
• Coordinate patch windows with application and storage teams because remediation requires kernel replacement and likely reboot.
• Track vendor advisories for exact fixed kernel package versions because no product-specific fixed versions were supplied in the input.