CVE-2026-46126

What it actually does

This is a Linux kernel vulnerability in the RDMA MANA driver error-handling path for RSS queue pair creation. If queue/work-queue setup fails during mana_ib_create_qp_rss(), incorrect unwind logic can either double-decrement the work-queue table index or fail to destroy a previously created work-queue object. A local user with the ability to exercise the affected RDMA interface can trigger inconsistent cleanup, resource leakage, or kernel instability, resulting primarily in denial of service. The CVSS vector indicates local access, low attack complexity, required low privileges, no user interaction, and high availability impact, with no expected confidentiality or integrity impact.

Why it matters to the business

Successful exploitation can disrupt Linux systems that use the affected MANA RDMA functionality, potentially causing service degradation, kernel errors, resource exhaustion, or host instability. The most likely business consequence is downtime or degraded performance for workloads depending on the affected kernel and RDMA/network acceleration stack. The risk is lower than remotely exploitable issues because exploitation requires local access and specific driver exposure, and there is no current KEV listing or known public exploit maturity, but multi-user compute, container, HPC, and cloud-hosted Linux environments should still prioritize assessment where RDMA/MANA is enabled.

How an attack unfolds

An attacker first needs local access to a Linux system running an affected kernel with the MANA RDMA driver available. The attacker then uses RDMA/InfiniBand interfaces or related userspace tooling to trigger RSS queue pair creation in a way that causes a failure in the setup sequence, such as during completion queue callback installation or work-queue object creation. When the driver enters its error-unwind path, the flawed cleanup logic mishandles the work-queue table: one failure path can decrement the index twice, while another can leave a created work-queue object uncleared. Repeating this condition may leak kernel/driver resources, corrupt expected driver state, or provoke kernel warnings, hangs, or crashes, resulting in a denial-of-service condition. There is no indication from the supplied intelligence that this CVE is being exploited by named threat actors or ransomware campaigns.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the RDMA/mana cleanup logic in mana_destroy_wq_obj() and mana_ib_create_qp_rss(). Because no exact fixed package versions were provided, use vendor advisories for the relevant Linux distribution, cloud image, appliance, or kernel package to identify the corrected kernel build. After updating, reboot into the fixed kernel and confirm the old vulnerable kernel is no longer running. If immediate patching is not possible, reduce exposure by disabling or unloading the MANA RDMA driver where it is not required, restricting local users who can access RDMA device nodes, limiting untrusted workloads on affected hosts, and applying container or workload isolation controls that prevent direct access to RDMA devices.

How to confirm the fix worked

Confirm exposure by checking whether the system is running an affected Linux kernel build and whether the MANA RDMA driver is present or loaded. Validate remediation by verifying that the running kernel version matches a vendor-fixed build, not just that the package is installed. Confirm with commands such as uname -r, distribution package manager queries, modinfo mana_ib, lsmod, and checks for RDMA devices under /sys/class/infiniband or /dev/infiniband. Review the vendor kernel changelog or source package to ensure it contains the RDMA/mana fix for mana_ib_create_qp_rss() cleanup. If the driver was disabled as a mitigation, validate that mana_ib is not loaded and that RDMA device nodes are not accessible to untrusted users.

Typical attack path

1. Obtain low-privileged local access to a Linux host running an affected kernel.
2. Confirm that the MANA RDMA driver and relevant RDMA device interfaces are present and accessible.
3. Use RDMA-capable userspace operations to initiate RSS queue pair creation.
4. Cause or induce a failure during the queue pair creation setup path, especially around completion queue callback installation or work-queue object creation.
5. Trigger the vulnerable error-unwind logic in mana_ib_create_qp_rss().
6. Repeat the operation as needed to consume resources, destabilize the RDMA driver, or cause kernel availability impact.

How to detect it

To assess whether exploitation may already have occurred, review kernel and system logs for repeated MANA RDMA driver errors, queue-pair creation failures, work-queue cleanup anomalies, kernel warnings, Oops reports, soft lockups, hung tasks, or unexplained reboots. Useful sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore artifacts, and monitoring alerts for host resets or RDMA device failures. Pay particular attention to events involving mana_ib_create_qp_rss(), mana_destroy_wq_obj(), mana_create_wq_obj(), mana_ib_install_cq_cb(), mana_ib, RDMA, or InfiniBand device access shortly before a crash or degradation event. Because this vulnerability is a logic flaw in kernel error cleanup, there may be no unique network indicator; detection is primarily host-based and behavioral. Correlate suspicious kernel events with local user sessions, container activity, RDMA tooling execution, and access to /dev/infiniband devices.

• mana_ib_create_qp_rss
• mana_destroy_wq_obj
• mana_create_wq_obj
• mana_ib_install_cq_cb
• mana_ib
• /dev/infiniband
• /sys/class/infiniband
• kernel: BUG:
• kernel: Oops:
• kernel: WARNING:
• kernel: soft lockup
• kernel: hung task
• general protection fault
• Call Trace:
• RDMA/mana
• mana:
• infiniband

What your security team should do

• Inventory Linux systems with MANA RDMA support enabled, prioritizing multi-user, container-hosting, HPC, AI/ML, and cloud compute hosts.
• Patch affected systems to a vendor-fixed kernel and reboot into the corrected kernel.
• If patching is delayed, disable or unload the mana_ib driver where RDMA/MANA functionality is not required.
• Restrict access to RDMA device nodes and ensure untrusted users or containers cannot directly exercise RDMA interfaces.
• Monitor kernel logs for RDMA/MANA errors, kernel warnings, Oops events, hangs, or repeated queue-pair creation failures.
• Treat unexplained host instability on systems with MANA RDMA enabled as potentially security-relevant until ruled out.
• Track vendor advisories because exact fixed versions vary by distribution and kernel packaging stream.