CVE-2026-46084

What it actually does

This flaw affects the Linux kernel MANA RDMA driver path for RSS queue pair destruction. When an RSS QP is destroyed, the driver tears down receive work queue objects without first disabling vPort RX steering in firmware. The firmware can therefore retain stale steering entries that reference already-destroyed receive objects. If traffic continues and the VF interface is later brought back up, firmware may deliver RX completions using stale completion queue identifiers that have been reused for other queues, including TX completion queues. This can cause incorrect completion handling, kernel warnings, queue corruption, denial of service, and potentially broader kernel memory corruption consistent with high confidentiality, integrity, and availability impact under the assigned CVSS vector.

Why it matters to the business

Systems using affected Linux kernels with the MANA Ethernet/RDMA stack may experience crashes, network disruption, or unsafe kernel behavior when RDMA or DPDK-style workloads create and destroy RSS queue pairs while traffic continues. In cloud or high-performance networking environments, this can interrupt workloads, degrade service availability, and create a local privilege-escalation risk if an attacker can exercise the vulnerable driver path. The vulnerability is not currently listed in CISA KEV, has no known mature public exploit, and has a low EPSS score, so urgency is highest for exposed systems running MANA RDMA, DPDK, or similar user-mode networking workloads rather than all Linux systems uniformly.

How an attack unfolds

An attacker first needs local access with sufficient privileges or capabilities to interact with the affected RDMA/MANA networking functionality, such as creating and destroying RSS queue pairs through RDMA or a DPDK-like workload. The attacker arranges for traffic to continue arriving from a peer while the RSS QP is destroyed. Because the vulnerable driver destroys RX work queue objects before disabling vPort RX steering, firmware can continue to reference stale RX steering state. The attacker then causes the VF interface to be brought back up or otherwise triggers the MANA open path, allowing firmware completions based on stale CQ IDs to be delivered into completion queues that may now belong to different objects, such as TX CQs. Successful exploitation can destabilize the kernel networking stack, trigger warnings or crashes, and may create conditions for kernel-level corruption with potential privilege escalation depending on memory reuse and timing.

How to fix it

Apply a Linux kernel update that includes the MANA driver fix to disable vPort RX steering before destroying RX work queue objects. Because no explicit fixed package versions were provided, use the fixed kernel packages supplied by the relevant Linux distribution, cloud image vendor, or upstream stable kernel branch once available. Prioritize hosts that use Microsoft Azure Network Adapter/MANA, RDMA, accelerated networking, DPDK, or other user-mode packet processing workloads. If immediate patching is not possible, reduce exposure by disabling unused RDMA functionality, avoiding MANA RDMA/DPDK workloads on affected kernels, limiting local access to users allowed to access RDMA devices, restricting membership in groups that grant device access, and stopping untrusted workloads from controlling VF bring-up/teardown or queue-pair lifecycle operations. A reboot into the fixed kernel is required for kernel-level remediation to take effect.

How to confirm the fix worked

Confirm the running kernel has been updated to a vendor build that includes the MANA change which disables vPort RX steering before RSS QP RX object destruction. Verify that affected modules such as mana, mana_ib, and related RDMA components are from the fixed kernel build. Review distribution advisories or kernel changelogs for references to disabling vPort RX steering on RSS QP destroy, mana_disable_vport_rx(), or RDMA/mana_ib RSS QP teardown. On systems where MANA/RDMA is not required, validate that the RDMA driver is not loaded and RDMA device access is unavailable to untrusted users. After patching and rebooting, exercise normal RDMA/DPDK lifecycle operations and check kernel logs for the absence of MANA completion queue warnings such as mana_poll_tx_cq, is_sq == false, mana_gd_process_eq_events, or cq_table lookup failures.

Typical attack path

1. Gain local access to a Linux system running an affected kernel with the MANA Ethernet/RDMA driver stack enabled.
2. Obtain the privileges or device access needed to use RDMA, DPDK, or another user-mode networking path that can create RSS queue pairs.
3. Create an RSS queue pair and establish receive steering through the MANA RDMA path.
4. Ensure that a peer continues sending network traffic toward the affected VF while queue teardown is occurring.
5. Destroy the RSS queue pair so the vulnerable driver removes RX work queue objects without disabling vPort RX steering in firmware.
6. Bring the VF interface back up or trigger the relevant MANA open/reinitialization path.
7. Cause stale firmware RX completions to be delivered to reused completion queue IDs, potentially corrupting queue state or crashing the kernel.

How to detect it

Look for evidence that the vulnerable MANA queue teardown and stale completion condition was triggered. Primary sources are kernel logs, journald, dmesg output, hypervisor or guest console logs, crash dumps, and monitoring alerts for kernel warnings or panics. Search for MANA and RDMA driver warnings involving TX completion queue polling receiving RX completions, failed completion queue table lookups, interface reopen events, DPDK process exits, RDMA workload restarts, and VF resets. Correlate suspicious warnings with local users or processes that had access to RDMA devices, DPDK applications, queue-pair lifecycle operations, or network interface administration. There are no known public exploit-specific artifacts, so detection should focus on behavioral indicators: repeated driver warnings, unexpected kernel panics, network device resets, RDMA/DPDK teardown immediately followed by continued peer traffic, and anomalous local activity around RDMA-capable devices.

• mana_poll_tx_cq
• mana_poll_tx_cq+0x1b8/0x220 [mana]
• is_sq == false
• mana_gd_process_eq_events
• mana_gd_process_eq_events+0x209/0x290
• cq_table lookup fails
• RDMA/mana_ib
• mana_ib_destroy_qp_rss
• mana_open
• mana_disable_vport_rx
• WARNING: mana_poll_tx_cq
• WARNING: mana_gd_process_eq_events
• [mana]

What your security team should do

• Inventory Linux systems using MANA, mana_ib, RDMA, accelerated networking, DPDK, or user-mode packet processing, and prioritize those for patching.
• Apply vendor-provided fixed kernel updates and reboot affected systems into the corrected kernel.
• Restrict local access and RDMA device permissions to trusted users and services until patching is complete.
• Temporarily disable unused RDMA or DPDK workloads on affected systems where operationally feasible.
• Add monitoring for MANA kernel warnings and completion queue lookup failures that may indicate the vulnerable condition was triggered.
• Review recent kernel logs around DPDK exits, RDMA workload restarts, VF interface resets, and network driver reloads for signs of stale completion delivery.
• Because this is not currently KEV-listed, has no known mature exploit, and has low EPSS, risk-rank it below remotely exploitable internet-facing issues but above ordinary local bugs on systems running the affected MANA RDMA path.