Skip to main content

Linux Kernel EUVDEUVD-2026-32318

| CVE-2026-45852 HIGH
Double Free (CWE-415)
2026-05-27 416baaa9-dc9f-4396-8d5f-8c081fb06d67 GHSA-m5rc-6p5x-73gp
Linux Information Disclosure
7.8
CVSS 3.1 · Vendor: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Share

Severity by source

Vendor (416baaa9-dc9f-4396-8d5f-8c081fb06d67) PRIMARY
7.8 HIGH
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
SUSE
HIGH
qualitative
Red Hat
7.0 HIGH
qualitative

Primary rating from Vendor (416baaa9-dc9f-4396-8d5f-8c081fb06d67).

CVSS VectorVendor: 416baaa9-dc9f-4396-8d5f-8c081fb06d67

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
May 30, 2026 - 11:23 vuln.today
CVSS changed
May 30, 2026 - 11:22 NVD
7.8 (HIGH)
Patch available
May 27, 2026 - 19:46 EUVD
CVE Published
May 27, 2026 - 14:16 nvd
HIGH 7.8
CVE Published
May 27, 2026 - 14:16 nvd
UNKNOWN (no severity yet)

DescriptionCVE.org

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

RDMA/rxe: Fix double free in rxe_srq_from_init

In rxe_srq_from_init(), the queue pointer 'q' is assigned to 'srq->rq.queue' before copying the SRQ number to user space. If copy_to_user() fails, the function calls rxe_queue_cleanup() to free the queue, but leaves the now-invalid pointer in 'srq->rq.queue'.

The caller of rxe_srq_from_init() (rxe_create_srq) eventually calls rxe_srq_cleanup() upon receiving the error, which triggers a second rxe_queue_cleanup() on the same memory, leading to a double free.

The call trace looks like this: kmem_cache_free+0x.../0x... rxe_queue_cleanup+0x1a/0x30 [rdma_rxe] rxe_srq_cleanup+0x42/0x60 [rdma_rxe] rxe_elem_release+0x31/0x70 [rdma_rxe] rxe_create_srq+0x12b/0x1a0 [rdma_rxe] ib_create_srq_user+0x9a/0x150 [ib_core]

Fix this by moving 'srq->rq.queue = q' after copy_to_user.

AnalysisAI

Local privilege escalation and kernel memory corruption in the Linux kernel's RDMA Soft RoCE (rxe) driver stems from a double-free in rxe_srq_from_init() when copy_to_user() fails after the queue pointer has already been assigned to srq->rq.queue. A local user with permission to create Shared Receive Queues over RDMA can trigger the error path to cause the same memory to be freed twice via rxe_srq_cleanup(), enabling kernel heap corruption with potential for privilege escalation. No public exploit identified at time of analysis and EPSS exploitation probability is very low (0.02%, 7th percentile).

Technical ContextAI

The flaw lives in drivers/infiniband/sw/rxe (Soft RoCE), the software RDMA-over-Ethernet provider in the Linux kernel's InfiniBand/RDMA stack. In rxe_srq_from_init(), the freshly allocated queue 'q' was attached to srq->rq.queue before copy_to_user() returned the SRQ number to user space; when the user-space copy fails, the function cleans up the queue via rxe_queue_cleanup() but does not null out srq->rq.queue, so the parent rxe_create_srq() error path invokes rxe_srq_cleanup() and frees the same kmem_cache object a second time. This is a classic CWE-415 (Double Free) on a slab-allocated object, exploitable as a use-after-free / heap grooming primitive against the kernel allocator. The fix reorders the assignment so srq->rq.queue is set only after copy_to_user() succeeds.

RemediationAI

Vendor-released patch is available: upgrade to a kernel containing one of the fixed versions (5.10.252, 5.15.202, 6.1.165, 6.6.128, 6.12.75, 6.18.14, 6.19.4, or 7.0) or the equivalent distribution backport, referencing the stable commits listed at https://git.kernel.org/stable/c/d286f0d4e3ad3caf5f0e673cdad7bf89bf37d947 and the other URLs in the NVD entry at https://nvd.nist.gov/vuln/detail/CVE-2026-45852. As a compensating control where patching is delayed, blacklist or unload the rdma_rxe module (echo 'blacklist rdma_rxe' > /etc/modprobe.d/blacklist-rxe.conf and rmmod rdma_rxe) since Soft RoCE is rarely required on general-purpose servers; the trade-off is loss of software-emulated RDMA over Ethernet for any workload that depends on it. Alternatively, restrict access to /dev/infiniband/uverbs* devices to a trusted group via udev rules so unprivileged local users cannot reach the vulnerable ioctl path, at the cost of breaking user-space RDMA applications for non-privileged accounts.

Same weakness CWE-415 – Double Free

View all
CVE-2014-0502 HIGH POC
8.8
CVE-2023-25136 MEDIUM POC
6.5
CVE-2014-1767 HIGH POC
7.2
CVE-2016-5768 CRITICAL POC
9.8
CVE-2016-5772 CRITICAL POC
9.8
CVE-2016-3132 CRITICAL POC
9.8
CVE-2017-6074 HIGH POC
7.8
CVE-2017-9287 MEDIUM POC
6.5

Same technique Information Disclosure

View all
CVE-2013-2251 CRITICAL POC
9.8
CVE-2017-5638 CRITICAL POC
9.8
CVE-2025-24813 CRITICAL POC
9.8
CVE-2015-1701 HIGH POC
7.8
CVE-2017-0147 HIGH POC
7.5
CVE-2014-6324 HIGH POC
8.8
CVE-2023-7028 CRITICAL POC
10.0
CVE-2017-0213 HIGH POC
7.3

Vendor StatusVendor

SUSE

Severity: High
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed
SUSE Linux Enterprise High Performance Computing 15 SP7 Fixed

Share

EUVD-2026-32318 vulnerability details – vuln.today
Back

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