CVE-2026-46181

What it actually does

This is a Linux kernel race condition in the Mellanox mlx4 RDMA driver path for shared receive queue (SRQ) events. The vulnerable code incorrectly relies on RCU-style assumptions for an object that is not safely lifetime-managed with RCU and may also be referenced before initialization is complete. A local user with access to the affected RDMA device interface could trigger timing-sensitive event handling that causes use of a partially initialized or freed kernel object, potentially leading to kernel memory corruption, denial of service through a crash, and in worst cases local privilege escalation with kernel-level code execution.

Why it matters to the business

Systems using affected Linux kernels with mlx4-based RDMA/Infiniband or RoCE hardware may be exposed to local privilege escalation or kernel crashes. The practical risk is highest on shared compute platforms, HPC clusters, virtualization hosts, storage fabrics, and multi-user Linux servers where untrusted or semi-trusted users can access RDMA capabilities. Although this issue is not in CISA KEV, has no known mature public exploit, and has a low EPSS score, the CVSS impact is high because successful exploitation can compromise the entire host or disrupt workloads.

How an attack unfolds

An attacker first needs local access to a vulnerable Linux system and sufficient permissions to interact with RDMA resources backed by the mlx4 driver. They then create or manipulate shared receive queue objects and attempt to cause asynchronous mlx4 SRQ events to be delivered during object initialization or teardown. Because the vulnerable code does not correctly protect the SRQ object lifetime, a race may allow the event handler to operate on an object that is not fully initialized or is no longer safely referenced. Depending on kernel layout, timing, and hardening controls, this may result in a kernel oops/panic or potentially controlled memory corruption that can be shaped into privilege escalation.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for RDMA/mlx4 SRQ event lifetime handling. Because no exact fixed package versions were provided, use the fixed kernel packages from the relevant Linux distribution or vendor advisory once available. Prioritize updates on systems with Mellanox ConnectX-3/ConnectX-3 Pro or other mlx4-supported RDMA hardware, especially shared compute and multi-user systems. If immediate patching is not possible, reduce exposure by disabling or unloading unused mlx4 RDMA modules, restricting access to RDMA character devices and RDMA-capable user groups, disabling RDMA services where not required, and limiting local shell access to trusted administrators.

How to confirm the fix worked

Confirm that affected systems are running a vendor kernel containing the RDMA/mlx4 fix for the SRQ event RCU misuse. Validate exposure by checking whether mlx4-related kernel modules are loaded and whether RDMA devices are present. Review distribution changelogs or kernel package metadata for the specific fix. After upgrading, reboot into the fixed kernel and verify the running kernel version rather than only confirming that a package is installed. Where RDMA is not required, confirm that mlx4 RDMA modules are not loaded and RDMA device nodes are not accessible to untrusted users.

Typical attack path

1. Obtain local shell or code execution as an unprivileged or low-privileged user on a Linux host with affected mlx4 RDMA driver support.
2. Confirm that Mellanox mlx4 RDMA/Infiniband/RoCE devices and userspace RDMA interfaces are available.
3. Create, destroy, or manipulate RDMA shared receive queue resources while inducing mlx4 SRQ events.
4. Race SRQ event delivery against SRQ initialization or teardown to trigger unsafe object access in the kernel driver.
5. Cause a kernel crash for denial of service or attempt to convert the memory-safety condition into kernel privilege escalation.
6. If privilege escalation succeeds, execute with elevated privileges and disable logging, persist, or move laterally from the compromised host.

How to detect it

Retrospective detection is difficult because exploitation occurs inside kernel timing and object-lifetime handling and may leave no clean application-level audit trail. Review kernel logs, persistent journal entries, crash dumps, and monitoring alerts for mlx4, RDMA, SRQ, or kernel oops/panic activity, especially shortly after RDMA resource creation or from sessions owned by non-administrative users. Examine access to /dev/infiniband/* and audit records for users or processes opening RDMA device files unexpectedly. On systems configured for kdump, analyze vmcore files for call traces involving mlx4_srq_event or mlx4_ib. Correlate suspicious kernel crashes with recent local logins, batch jobs, container workloads, or user processes interacting with libibverbs/RDMA APIs. Absence of these artifacts does not prove non-exploitation because a successful local privilege escalation may not crash the host.

• mlx4_srq_event
• mlx4_ib
• mlx4_core
• RDMA/mlx4
• /dev/infiniband/uverbs
• /dev/infiniband/rdma_cm
• /sys/class/infiniband/mlx4_
• libibverbs
• kernel: BUG:
• kernel: Oops:
• kernel panic
• Call Trace:

What your security team should do

• Inventory Linux systems with mlx4 RDMA hardware or loaded mlx4 kernel modules and prioritize them for patching.
• Patch or upgrade affected kernels using vendor-provided fixed packages, then reboot to ensure the fixed kernel is active.
• Treat shared HPC, virtualization, storage, and multi-user Linux hosts as higher priority because local users may be able to reach RDMA interfaces.
• Temporarily disable unused RDMA functionality or unload mlx4-related modules where operationally safe.
• Restrict membership in groups or permissions that allow access to RDMA device files such as /dev/infiniband/*.
• Monitor kernel logs for mlx4, RDMA, SRQ, or kernel oops/panic events that could indicate probing or attempted exploitation.
• Because there is no known KEV listing or mature public exploit, manage this as a high-impact local privilege escalation rather than an internet-scale emergency.