CVE-2026-46145

What it actually does

This is a local Linux kernel memory corruption vulnerability in the RDMA mana driver. A userspace-controlled uAPI field, rx_hash_key_len, is passed to memcpy without sufficient bounds validation, allowing a privileged local user with access to the relevant RDMA interface to write beyond the intended kernel buffer. Successful exploitation can corrupt kernel memory and may allow local privilege escalation, information disclosure, or kernel crash/denial of service.

Why it matters to the business

Systems running affected Linux kernels with the MANA RDMA driver exposed to local users or workloads may be vulnerable to full host compromise from an already-authenticated account or compromised container/workload with sufficient device access. The main operational risks are privilege escalation, loss of workload isolation, kernel crashes, and unauthorized access to sensitive data on the host. This issue is not currently listed in CISA KEV, has low EPSS, and has no public exploit maturity reported, but kernel memory corruption flaws should still be prioritized on multi-user, virtualization, cloud, and high-performance networking systems.

How an attack unfolds

An attacker first obtains local code execution or an authenticated shell on a Linux system where the affected RDMA MANA driver is loaded and accessible. They then interact with the RDMA userspace API and submit a crafted structure containing an oversized rx_hash_key_len value. Because the vulnerable kernel path trusts that length and passes it to memcpy, the copy operation can overwrite adjacent kernel memory. Depending on kernel configuration, allocator layout, mitigations, and driver state, the attacker may use the overwrite to crash the kernel or shape memory corruption into privilege escalation, such as gaining root privileges or escaping a restricted workload context with access to the RDMA device.

How to fix it

Upgrade to a Linux kernel version that includes the RDMA/mana fix validating rx_hash_key_len before memcpy. If using a distribution kernel, apply the vendor security update rather than relying only on upstream version numbers. If immediate patching is not possible, reduce exposure by disabling or unloading the MANA RDMA driver where it is not required, removing access to RDMA/uverbs device nodes from untrusted users and containers, restricting local shell access, and enforcing least-privilege device passthrough policies. Kernel hardening features such as KASLR, SMEP/SMAP, hardened usercopy, slab freelist hardening, and lockdown mode may reduce exploit reliability but should not be treated as complete mitigations.

How to confirm the fix worked

Confirm that systems are running a kernel build containing the fix for RDMA/mana rx_hash_key_len validation. On distribution-managed systems, verify the installed kernel package against the vendor advisory and reboot into the patched kernel. Check whether the MANA RDMA module is present or loaded using standard module and hardware inventory commands, and verify whether RDMA/uverbs device nodes are exposed to users or containers. Where source validation is applicable, confirm the driver code bounds-checks rx_hash_key_len before copying the RX hash key. After remediation, ensure no vulnerable kernel remains bootable as the default or fallback image on production systems.

Typical attack path

1. Gain local authenticated access or code execution on a Linux host running an affected kernel.
2. Confirm the MANA RDMA driver/device is present and accessible from userspace.
3. Open the relevant RDMA/uverbs interface from userspace.
4. Submit a crafted RDMA configuration/request containing an oversized rx_hash_key_len value.
5. Trigger the unchecked memcpy in the kernel driver.
6. Use the resulting kernel memory corruption to crash the host or attempt local privilege escalation.

How to detect it

Post-exploitation detection is difficult because successful exploitation occurs inside the kernel and may leave few application-level traces. Review kernel logs, crash dumps, audit logs, and endpoint telemetry from affected systems. Focus on signs of kernel memory corruption involving the RDMA MANA driver, unexpected host crashes or reboots, KASAN/slab out-of-bounds reports, general protection faults, and local processes opening RDMA device nodes such as /dev/infiniband/uverbs*. Correlate these events with user sessions, container activity, privilege changes, new root-owned files, unexpected setuid binaries, and suspicious process execution shortly before a crash or privilege escalation. If crash dumps are available, inspect call traces for mana_ib, RDMA, ib_uverbs, and memcpy-related paths. No named threat actors or ransomware campaigns are currently associated with this vulnerability based on the supplied information.

• /dev/infiniband/uverbs
• /dev/infiniband/rdma_cm
• mana_ib
• mana.ko
• drivers/infiniband/hw/mana
• rx_hash_key_len
• KASAN: slab-out-of-bounds
• KASAN: out-of-bounds
• BUG: kernel NULL pointer dereference
• general protection fault
• kernel panic
• Oops:
• Call Trace:
• ib_uverbs
• RDMA/mana

What your security team should do

• Prioritize patching Linux hosts that use MANA RDMA, accelerated networking, virtualization, cloud networking, or multi-tenant workloads.
• Inventory systems for loaded MANA/RDMA drivers and exposed /dev/infiniband device nodes.
• Apply vendor kernel updates and reboot into the patched kernel; verify the running kernel, not just the installed package.
• Temporarily remove untrusted user or container access to RDMA/uverbs devices until patching is complete.
• Disable or unload the MANA RDMA driver on systems where it is not operationally required.
• Monitor for kernel crashes, KASAN reports, general protection faults, or anomalous local processes interacting with RDMA device nodes.
• Treat unexplained crashes on affected hosts as potential security events and preserve kernel logs, vmcore dumps, and process accounting data for review.