CVE-2026-46189

What it actually does

This is a Linux kernel memory-corruption flaw in the VMware paravirtual RDMA driver, vmw_pvrdma. During failure handling in pvrdma_alloc_ucontext(), the driver can free the same user access region twice because pvrdma_uar_free() is called directly and then again through pvrdma_dealloc_ucontext(). A local authenticated user who can interact with the affected RDMA device may be able to trigger the error path, causing kernel heap corruption. Practical outcomes can include kernel panic, denial of service, or, depending on allocator state and exploit reliability, local privilege escalation to kernel-level execution.

Why it matters to the business

Systems using affected Linux kernels with the vmw_pvrdma driver exposed are at risk of local users or compromised low-privilege accounts destabilizing the host or potentially gaining full control. The CVSS score is high because successful exploitation can affect confidentiality, integrity, and availability at the operating-system level. However, the risk is moderated by the local-access requirement, low EPSS score, no known CISA KEV listing, no ransomware association, and no known public exploit maturity in the provided data. Multi-user Linux servers, virtualization environments, and workloads that expose RDMA devices to users or containers should prioritize review.

How an attack unfolds

An attacker first needs local code execution or an authenticated local account on a Linux system where the affected vmw_pvrdma kernel driver is present and reachable. The attacker then interacts with the RDMA userspace interface to create a user context and intentionally drives pvrdma_alloc_ucontext() into an error path. Because cleanup is performed incorrectly, the same memory-backed resource can be released twice. This double free corrupts kernel memory management state. In a simple exploitation scenario, this causes a kernel crash and denial of service. In a more advanced scenario, the attacker attempts to shape kernel heap allocations before and after the double free so that the corrupted object is reused in a controlled way, potentially enabling privilege escalation or kernel code execution. There is no indication from the provided intelligence that this vulnerability is currently exploited in the wild.

How to fix it

Apply a Linux kernel update from the relevant distribution or kernel vendor that includes the vmw_pvrdma double-free fix. No exact fixed package versions were provided, so remediation should be tracked through vendor advisories for the deployed kernel branch. Where immediate patching is not possible, reduce exposure by unloading or blacklisting the vmw_pvrdma module if VMware paravirtual RDMA is not required, restricting access to RDMA device nodes, and limiting local shell access to trusted users only. In virtualized environments, review whether RDMA devices are passed through or exposed to guests and disable that exposure where unnecessary. Kernel hardening features such as module-loading restrictions, lockdown mode, slab freelist hardening, and least-privilege container/device policies can reduce exploitability but should not be treated as a substitute for patching.

How to confirm the fix worked

Confirm the running kernel has been updated to a vendor build containing the fix, then reboot into that kernel and verify with uname and the platform package manager. Check whether vmw_pvrdma is loaded using lsmod, modinfo, or /sys/module/vmw_pvrdma. If the module is not required, validate that it cannot be loaded after mitigation by checking blacklist configuration and attempting a controlled module-load test in a maintenance window. Review /dev/infiniband permissions and RDMA device exposure to ensure only intended users or workloads can access RDMA interfaces. Validate patch status against distribution security advisories rather than relying only on upstream kernel version numbers, because many vendors backport fixes without changing to the newest upstream release.

Typical attack path

1. Obtain local access to a vulnerable Linux system, such as through a shell, compromised service account, or container with access to relevant RDMA devices.
2. Confirm that the vmw_pvrdma driver is loaded or that VMware paravirtual RDMA functionality is available.
3. Use RDMA userspace interfaces to request creation of a pvrdma user context.
4. Trigger an allocation or initialization failure during pvrdma_alloc_ucontext() so the vulnerable cleanup path executes.
5. Cause the driver to free the same resource twice, corrupting kernel heap state.
6. Leverage the corruption to crash the kernel or attempt local privilege escalation, depending on exploit sophistication and system hardening.

How to detect it

Look for signs of attempted exploitation or instability in kernel and system logs rather than relying on network indicators, because exploitation is local. Relevant sources include dmesg, journald, /var/log/kern.log, /var/log/messages, kernel crash dumps, kdump/vmcore artifacts, auditd logs for access to RDMA device nodes, and EDR telemetry showing local processes interacting with /dev/infiniband. Investigate kernel messages mentioning vmw_pvrdma near allocator errors, double-free reports, slab corruption, KASAN reports, general protection faults, or kernel panics. Correlate these events with local user sessions, recent process execution, container activity, and access to RDMA devices. If kernel crash dumps are available, inspect call traces for pvrdma_alloc_ucontext(), pvrdma_dealloc_ucontext(), or pvrdma_uar_free(). Absence of these artifacts does not prove non-exploitation, because a successful local privilege-escalation attempt may leave minimal logs unless it crashes or triggers kernel diagnostics.

• vmw_pvrdma
• pvrdma_alloc_ucontext
• pvrdma_dealloc_ucontext
• pvrdma_uar_free
• KASAN: double-free
• KASAN: slab-use-after-free
• BUG: kernel NULL pointer dereference
• general protection fault
• kernel BUG at
• double free
• slab corruption
• corrupted freelist
• /sys/module/vmw_pvrdma
• /dev/infiniband
• /var/crash
• /proc/vmcore

What your security team should do

• Inventory Linux systems for affected kernel versions and for presence or loading of the vmw_pvrdma driver.
• Prioritize patching systems where untrusted users, shared shell access, containers, or virtual machines can reach RDMA device interfaces.
• If VMware paravirtual RDMA is not required, disable or blacklist vmw_pvrdma as a compensating control until patched.
• Restrict permissions on RDMA device nodes and review container, VM, and workload device passthrough policies.
• Monitor kernel logs for memory-corruption, double-free, KASAN, slab, or vmw_pvrdma-related crash messages.
• Treat unexplained kernel panics on systems with vmw_pvrdma loaded as potential security events and preserve crash dumps for analysis.
• Because this is not listed in KEV and has low EPSS in the provided data, handle through normal high-severity kernel patch cycles unless local untrusted access to RDMA devices is present.