Skip to main content
VulnerabilityPublished Updated

CVE-2026-53187: Linux kernel · RDMA/core: Validate cpu_id against nr_cpu_ids in DMAH alloc

Affects Linux kernelSource CVE Database V5

0

Not known to be exploited · CVSS 7.1 High · fixed in bd5e818be7964c1689fba2dad9e6bd3a827fee74 : patch Linux kernel soon.

Data as of 26 Oct 2026, 14:05 UTC

CVSS 3.1 base score
7.1High
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.1% chance of exploitation in 30 days – higher than 5% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CISA SSVC
Exploitation
No evidence of active exploitation and no public proof of concept
Automatable
Attackers cannot reliably automate steps 1–4 of the kill chain
Technical impact
Limited control over the software or limited information exposure

CISA SSVC assessment, 2026-10-16.

Patch
Available – fixed in bd5e818be7964c1689fba2dad9e6bd3a827fee74, 323c98a4ff06aa28114f2bf658fb43eb3b536bbc, 0efbb6b54ff56300867027d8e0800d0e32226a20
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 25 Jun 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade Linux kernel to bd5e818be7964c1689fba2dad9e6bd3a827fee74, 323c98a4ff06aa28114f2bf658fb43eb3b536bbc or 0efbb6b54ff56300867027d8e0800d0e32226a20.

Affected software

ProductAffectedFixed in
LinuxLinuxAffected
  • ≥ d83edab562a496a42720902a1d2effccd05c37c5, < bd5e818be7964c1689fba2dad9e6bd3a827fee74
Fixed in
  • bd5e818be7964c1689fba2dad9e6bd3a827fee74
LinuxLinuxAffected
  • ≥ d83edab562a496a42720902a1d2effccd05c37c5, < 323c98a4ff06aa28114f2bf658fb43eb3b536bbc
Fixed in
  • 323c98a4ff06aa28114f2bf658fb43eb3b536bbc
LinuxLinuxAffected
  • ≥ d83edab562a496a42720902a1d2effccd05c37c5, < 0efbb6b54ff56300867027d8e0800d0e32226a20
Fixed in
  • 0efbb6b54ff56300867027d8e0800d0e32226a20
LinuxLinuxAffected
  • =6.17
Fixed in–

Description

In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Validate cpu_id against nr_cpu_ids in DMAH alloc The cpu_id attribute supplied by user space through UVERBS_ATTR_ALLOC_DMAH_CPU_ID is passed directly to cpumask_test_cpu() without first verifying that the value is within the valid CPU range. Passing such untrusted data to cpumask_test_cpu() may lead to an out-of-bounds read of the underlying cpumask bitmap: the helper expands to a test_bit() that indexes the bitmap by cpu_id / BITS_PER_LONG with no bound check. In addition, on kernels built with CONFIG_DEBUG_PER_CPU_MAPS it trips the WARN_ON_ONCE() in cpumask_check(); combined with panic_on_warn this turns a bad user input into a machine reboot. Reject any cpu_id that is not smaller than nr_cpu_ids with -EINVAL before it is used. Reported by Smatch.

References

Community reviews

Loading reviews…