Skip to main content

Linux Kernel EUVDEUVD-2026-38037

| CVE-2026-52908 HIGH
2026-06-19 Linux GHSA-2m6m-r8c9-84hh
7.8
CVSS 3.1 · Vendor: Linux
Share

Severity by source

Vendor (Linux) PRIMARY
7.8 HIGH
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
vuln.today AI
7.8 HIGH

Local RDMA verbs access with low privileges and no user interaction yields PR:L/AV:L; RO-to-RW mispin enables memory corruption giving high C/I/A.

3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
4.0 AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (Linux).

CVSS VectorVendor: Linux

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

5
Analysis Generated
Jun 28, 2026 - 10:30 vuln.today
CVSS changed
Jun 28, 2026 - 08:22 NVD
7.8 (HIGH)
Patch available
Jun 19, 2026 - 16:01 EUVD
CVE Published
Jun 19, 2026 - 14:00 cve.org
UNKNOWN (no severity yet)
CVE Published
Jun 19, 2026 - 14:00 cve.org
HIGH 7.8

DescriptionCVE.org

In the Linux kernel, the following vulnerability has been resolved:

RDMA: During rereg_mr ensure that REREG_ACCESS is compatible

If IB_MR_REREG_ACCESS changes from RO to RW then the umem has to be re-evaluated to ensure it is properly pinned as RW. Since the umem is hidden inside each driver's mr struct add a ib_umem_check_rereg() function that each driver has to call before processing IB_MR_REREG_ACCESS.

mlx4 has to retain its duplicate ib_access_writable check because it implements IB_MR_REREG_ACCESS | IB_MR_REREG_TRANS by changing both items in place sequentially while the MR is live, so it will continue to not support this combination.

AnalysisAI

Improper access-control re-validation in the Linux kernel's RDMA/InfiniBand subsystem (the ib_uverbs memory-region re-registration path) allows a local user with RDMA device access to obtain unintended read-write access to memory that was only pinned as read-only. When IB_MR_REREG_ACCESS upgrades a memory region from RO to RW, the underlying umem was not re-evaluated to confirm it is properly pinned for writing, enabling potential memory corruption or disclosure across RDMA-capable drivers. …

Unlock full vulnerability intelligence

  • Risk assessment & exploitation conditions
  • Attack chain visualization
  • Remediation with exact patch versions
  • Threat intelligence from 22 sources
  • Personal watchlist & email alerts

Free forever · No credit card required

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata

Access
Gain local access to RDMA device
Delivery
Register memory region read-only
Exploit
Issue rereg_mr changing access RO to RW
Execution
Device writes to non-revalidated pinned pages
Persist
Corrupt kernel memory or disclose data
Impact
Escalate privileges locally

Vulnerability AssessmentAI

Exploitation Exploitation requires local access to a system with RDMA/InfiniBand functionality enabled and reachable from the attacker's context - specifically the ability to open an ib_uverbs device and invoke the memory-region re-registration (rereg_mr) verb with the IB_MR_REREG_ACCESS flag transitioning a region from read-only to read-write. … Additional conditions and limiting factors are described in the full assessment.
Risk Assessment The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, base 7.8) describes a local, low-complexity attack requiring low privileges and no user interaction, with high confidentiality, integrity, and availability impact - consistent with local memory corruption/disclosure rather than a remote network threat. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in.
Exploit Scenario A local user (or a process inside a container that has been granted access to an RDMA uverbs device) registers a memory region with read-only access, then issues a re-registration request that flips the access flags from RO to RW; because the umem is not re-pinned as writable, the attacker can drive the device to write into pages that were never validated for write, corrupting kernel-managed memory to escalate privileges or disclose data. No user interaction is required and attack complexity is low, but the attacker must already have local RDMA verbs access; no public exploit code has been identified at time of analysis.
Remediation Apply the vendor-released kernel patch by upgrading to a fixed stable release: 6.6.143, 6.12.94, 6.18.36, 7.0.13, or 7.1 (or later), per the kernel.org stable commits 50334a05a950840b39a1ce3d2a173b4183db9b3e, 09dc18894148381d3bfc550083b1236043870dce, eba5df21eda0fe7418efbea2f799f8ea1b8ca94c, 2904e985a2917b5dac65df82733065e78a65fc9d, and badad6fad60def1b9805559dd81dbab3d97b82aa (all under https://git.kernel.org/stable/c/). … Detailed patch versions, workarounds, and compensating controls in full report.

Recommended ActionAI

Within 24 hours: Identify all systems running RDMA/InfiniBand by querying kernel modules (rdma, ib_uverbs); request current patched stable kernel version from your Linux distribution. …

Sign in for detailed remediation steps and compensating controls.

Threat intelligence, references, and detailed analysis are available after sign-in.

Share

EUVD-2026-38037 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy