CVE-2026-46144

What it actually does

This is a local denial-of-service vulnerability in the Linux kernel RDMA MANA driver. An error-handling path in mana_ib_create_qp_rss() fails to release resources allocated by mana_ib_cfg_vport_steering() when queue pair creation fails. A local user with the ability to exercise the affected RDMA/MANA code path could repeatedly trigger the failure condition and leak kernel or device-driver resources, potentially causing memory pressure, degraded RDMA networking behavior, driver instability, or a system-level availability impact. The CVSS vector indicates local access is required, exploitation is low complexity, privileges are required, and the primary impact is availability rather than confidentiality or integrity.

Why it matters to the business

Systems using affected Linux kernels with the Microsoft Azure Network Adapter RDMA/MANA driver may be vulnerable to local resource-exhaustion conditions. In practical terms, a malicious or compromised local workload could degrade network/RDMA functionality or destabilize the host, causing application outages, interrupted compute workloads, or node reboots. The risk is lower than a remotely exploitable flaw because an attacker needs local privileges and a relevant hardware/driver configuration, and there is no current KEV listing or known public exploit maturity; however, shared compute, multi-user Linux, HPC, virtualization, and cloud workloads that expose RDMA capabilities should treat this as an availability hardening issue.

How an attack unfolds

An attacker first obtains local execution with sufficient privileges or device access to interact with RDMA functionality on a system running an affected Linux kernel with the MANA RDMA driver loaded. The attacker then repeatedly invokes operations that cause RSS queue pair creation through the mana_ib_create_qp_rss() path while forcing or inducing an error condition after vport steering configuration has been allocated. Because the vulnerable unwind path does not clean up the steering configuration, each failed attempt leaks resources. Over time, repeated attempts can consume kernel or driver resources, leading to RDMA service degradation, allocation failures, kernel warnings, networking disruption, or host instability. This vulnerability is not expected to provide direct code execution or data theft by itself; the abuse case is primarily denial of service.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the RDMA/mana error-unwind leak in mana_ib_create_qp_rss(). Because no exact fixed package versions were provided, use the fixed kernel release supplied by the relevant Linux distribution, cloud image provider, appliance vendor, or kernel maintainer. Reboot into the patched kernel after installation and verify the running kernel, not just the installed package, has been updated. If immediate patching is not possible, reduce exposure by restricting local access to RDMA device nodes and RDMA-capable workloads, disabling or unloading the MANA RDMA driver where it is not required, limiting access to privileged containers or host device passthrough, and using workload isolation controls to prevent untrusted users from exercising RDMA verbs on affected hosts.

How to confirm the fix worked

Confirm exposure by checking whether the system is running an affected Linux kernel and whether the MANA RDMA driver is present or loaded. Validate remediation by verifying the running kernel version is the vendor-patched version and that the patch containing the mana_ib_create_qp_rss() unwind fix is included. On source-based or custom kernels, confirm the RDMA/mana driver cleanup path releases vport steering resources when QP RSS creation fails. Operationally, monitor after patching for absence of repeated mana_ib-related allocation failures, RDMA queue pair creation failures, kernel memory pressure, or instability under RDMA workload testing. A reboot is typically required for kernel fixes to take effect.

Typical attack path

1. Gain local shell, process execution, or workload execution on a Linux system using an affected kernel and the MANA RDMA driver.
2. Confirm RDMA/MANA capabilities are present, such as a loaded mana_ib driver and accessible RDMA device interfaces.
3. Run code or tooling that repeatedly requests RSS queue pair creation through the affected RDMA verbs path.
4. Trigger failure cases during mana_ib_create_qp_rss() after vport steering configuration has been allocated.
5. Repeat the operation to accumulate leaked kernel or driver resources.
6. Cause RDMA failures, memory/resource exhaustion, kernel instability, service degradation, or host-level denial of service.

How to detect it

Look for evidence of local resource-exhaustion attempts against RDMA/MANA functionality. Useful sources include kernel logs, system journal entries, audit logs for access to RDMA device nodes, process accounting, EDR telemetry, container runtime device-mount records, and monitoring for memory pressure or RDMA driver errors. Investigate repeated failures involving mana_ib, MANA, RDMA queue pair creation, vport steering, allocation failures, or sudden host instability correlated with local processes interacting with /dev/infiniband devices. Because this vulnerability is a resource leak rather than a payload-driven exploit, there may be no unique exploit signature; detection should focus on abnormal repetition, local access to RDMA devices, and host symptoms such as OOM events, kernel warnings, RDMA communication failures, or unexplained node reboots. No named threat actor activity or KEV exploitation is currently associated with this issue based on the provided data.

• mana_ib
• mana_ib_create_qp_rss
• mana_ib_cfg_vport_steering
• RDMA/mana
• /dev/infiniband
• /sys/class/infiniband
• Out of memory
• oom-killer
• allocation failure
• kernel: mana_ib
• QP creation failed
• vport steering

What your security team should do

• Prioritize patching Linux systems that use RDMA/MANA networking, especially cloud, HPC, virtualization, and shared compute nodes where local users or workloads may be less trusted.
• Inventory systems with the mana_ib kernel module loaded or RDMA MANA devices present, then map them to vendor kernel advisories and patched kernel releases.
• Restrict access to RDMA device interfaces and avoid exposing RDMA devices to untrusted containers, tenants, or local users until patched.
• If RDMA/MANA is not required, disable or unload the mana_ib driver as a temporary mitigation, following vendor guidance.
• Monitor kernel logs and telemetry for repeated mana_ib, RDMA, queue pair creation, allocation failure, memory pressure, or driver reset events.
• Ensure patch validation checks the active running kernel after reboot, not only installed package metadata.
• For custom kernels, backport the upstream RDMA/mana fix and perform regression testing around RDMA queue pair creation and failure handling.