dbcve.org
Linux KernelOperating system · Linux

CVE-2026-53186

CRITICAL · 9.1 CVSS v3.1 Published 2026-06-25
Fix available
A fix is available. Upgrade to 5.10.259 / 5.15.210 or later.
See remediation →
100/100
Remediation priority · Urgent
Remotely reachable No privileges Zero-click Patch available

Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.

NVD · unedited
In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: bound SRP_RSP sense copy by the received length srp_process_rsp() copies sense data from rsp->data + resp_data_len, where resp_data_len is the full 32-bit value supplied by the SRP target and is never checked against the number of bytes actually received (wc->byte_len). The copy length is bounded to SCSI_SENSE_BUFFERSIZE, so at most 96 bytes are copied, but the source offset is not bounded. A malicious or compromised SRP target on the InfiniBand/RoCE fabric that the initiator has logged into can return an SRP_RSP with SRP_RSP_FLAG_SNSVALID set and a large resp_data_len. The receive buffer is allocated at the target-chosen max_ti_iu_len, so the source of the sense copy lands past the bytes actually received; with resp_data_len near 0xFFFFFFFF it is gigabytes past the buffer and the read faults. Copy the sense data only if it has not been truncated, that is, only if the response header, the response data, and the sense region fit within the bytes actually received; otherwise drop the sense and log. The in-tree iSER and NVMe-RDMA receive paths already bound their parse by wc->byte_len; this brings ib_srp into line with them.

Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.

dbcve analysis · high confidence

In the Linux kernel's RDMA/srp driver, the srp_process_rsp() function copies sense data from an offset calculated using resp_data_len (a 32-bit value from the SRP target) without validating it against the actual received bytes (wc->byte_len). A malicious target can specify a large resp_data_len causing the copy source to land beyond the received buffer, triggering a kernel read fault. The fix adds bounds checking to ensure the response header, data, and sense region all fit within actually received bytes.

MitigationApply the kernel patch which adds wc->byte_len validation before copying sense data. In the interim, restrict SRP/InfiniBand/RoCE fabric access to trusted targets only.

Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.

Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.

NVD · CPE data
Linux KernelOperating system
Affected:>= 2.6.15, < 5.10.259>= 5.11, < 5.15.210>= 5.16, < 6.1.176>= 6.2, < 6.6.143>= 6.7, < 6.12.94>= 6.13, < 6.18.36>= 6.19, < 7.0.13= 7.1

CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.

From the vector
Attack vector
Network
Complexity
Low
Privileges
None
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
None
Availability
High

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H

Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.

dbcve checks

Work through these to decide whether this CVE applies to you.

  1. Check kernel version against affected ranges
    Run 'uname -r' or 'cat /proc/version' to get the kernel version, then compare it to: < 5.10.259, 5.11-5.15.209, 5.16-6.1.175, 6.2-6.6.142, 6.7-6.12.93, 6.13-6.18.35, 6.19-7.0.12, or 7.1
    Affected if The kernel version falls within any of the affected ranges listed above
  2. Verify if SRP driver is loaded
    Run 'lsmod | grep srp' or check /sys/module/srp' to see if the srp module is currently loaded in memory
    Affected if The srp kernel module is loaded into memory
  3. Check for active RDMA devices
    Run 'rdma link' or 'ibstat' (if available) to list active RDMA/InfiniBand/RoCE devices and connections
    Affected if Any RDMA devices or SRP connections are present and active on the system
  4. Inspect SRP target configuration
    Check /sys/class/infiniband_srp/ or run 'srp_daemon -c' (if available) to list configured SRP targets
    Affected if Any SRP targets are configured or connected on the system

A system is affected if it runs a kernel version within the vulnerable ranges AND has the SRP driver loaded with active RDMA/SRP connections or configured targets.

Generated from the published advisory. Verify against your own configuration.

Check your environment

Paste your version and any relevant configuration and it will be compared against the affected criteria above. Do not include secrets or credentials.

AI-assisted, checked against the advisory. Informational, not a guarantee.

Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.

dbcve · scoped
Upgrade available Upgrade to 5.10.259 / 5.15.210 / 6.1.176 or later
Fixed in 5.10.2595.15.2106.1.176
Vendor patch git.kernel.org →
Interim mitigation

Apply the kernel patch which adds wc->byte_len validation before copying sense data. In the interim, restrict SRP/InfiniBand/RoCE fabric access to trusted targets only.

Recommended fix High confidence

Upgrade to one of: Linux 5.10.259+, 5.15.210+, 6.1.176+, or 6.6.143+ (or the latest stable release in your respective branch)

  1. 1. Identify the current running kernel version using 'uname -r'
  2. 2. Determine which version branch your current kernel belongs to (e.g., 5.10.x, 5.15.x, 6.1.x, 6.6.x)
  3. 3. For kernels in the 5.10.x branch (< 5.10.259): upgrade to 5.10.259 or later
  4. 4. For kernels in the 5.15.x branch (< 5.15.210): upgrade to 5.15.210 or later
  5. 5. For kernels in the 6.1.x branch (< 6.1.176): upgrade to 6.1.176 or later
  6. 6. For kernels in the 6.6.x branch (< 6.6.143): upgrade to 6.6.143 or later
  7. 7. Apply the upgrade via your distribution's package manager (e.g., apt-get update && apt-get upgrade, yum update, dnf upgrade)
  8. 8. Reboot the system to load the new kernel
Caveat Kernel upgrades may require rebooting services; ensure compatibility with userspace tools and any custom drivers/modules before upgrading

Generated from the published advisory — verify against the referenced sources before acting.

Fix this in Linux Kernel Scoped from the published advisory
  • Consultation2.0 h
  • Implementation4.0 h
  • Testing6.0 h
  • Review / QA3.0 h
15.0 hours of engineering $2,560
Get the upgrade done

An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $4,096.

Scan for this in your stack

Free · runs locally
dbcve dependency scanner

Check whether your project pulls in CVE-2026-53186 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.

Get it on GitHub Scan in the browser

References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.

Primary sources

Practitioner notes

Contributed

Peer-ranked notes from engineers who’ve handled CVE-2026-53186 in production — separate from our analysis above.

No notes yet

Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.

What this is

A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.

What belongs here
  • Verified mitigations, workarounds, and config changes
  • Version or environment caveats, and links to real fixes
  • No weaponised exploit code, or anything meant to cause harm
  • No spam, self-promotion, credentials, or personal data