CVE-2026-64034

What it actually does

This is a Linux kernel race condition in the Microsoft Azure Network Adapter (MANA) hardware communication receive path. The driver reads a message identifier from DMA-coherent memory, validates it, and later reads the same DMA-backed value again when using it for bit operations and pointer arithmetic. Because DMA-coherent memory can be modified by hardware or a controlling host between those two reads, the second value can differ from the validated value. That time-of-check/time-of-use double-fetch can bypass bounds checking and may allow out-of-bounds access or kernel memory corruption in the guest, with potential confidentiality, integrity, and availability impact.

Why it matters to the business

Systems using affected Linux kernels with the MANA network driver are at risk of guest kernel compromise or crash if an attacker can influence the DMA-visible device/host side. This is most relevant to virtualized and cloud workloads, including confidential VM scenarios where the host can still observe or modify shared DMA buffers. Although there is no known public exploit, it has a high severity score and can affect system availability and isolation guarantees, so organizations running Linux on platforms that expose MANA networking should prioritize kernel updates during the next urgent maintenance window.

How an attack unfolds

An attacker positioned to manipulate the DMA-coherent response buffer used by the MANA driver waits for the guest kernel to process a hardware communication response. The driver first reads response.hwc_msg_id and checks that it is within an expected range. Before the driver reuses the field, the attacker changes the DMA-backed value. The driver then fetches the modified value and uses it in test_bit() logic and pointer calculations inside the response handler. Because the second value was not the one that was validated, the attacker may steer the kernel into out-of-bounds memory access, potentially causing a kernel crash or corruption that could be developed into code execution in the guest kernel. No active exploitation, KEV listing, ransomware use, or named threat actor activity is currently reported for this vulnerability.

How to fix it

Apply a Linux kernel version that includes the upstream fix for the MANA driver. The corrected implementation reads hwc_msg_id exactly once with READ_ONCE() into a stack-local variable in mana_hwc_rx_event_handler(), validates that local value, and passes the validated value into mana_hwc_handle_resp() instead of re-reading from DMA memory. No exact fixed package versions were provided in the input, so use the fixed kernel packages from the relevant Linux distribution or vendor advisory. Where immediate patching is not possible, reduce exposure by avoiding affected kernels on platforms using the MANA network driver, moving workloads to kernels without the vulnerable driver path, disabling or not attaching MANA-backed networking where operationally feasible, and ensuring strong control over hypervisor, host, and device-management planes.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package is at or above the version identified as fixed by the operating system vendor. For source-based validation, inspect the MANA driver code and confirm that mana_hwc_rx_event_handler() reads response.hwc_msg_id once using READ_ONCE(), stores it in a local variable, validates that local variable, and passes it as an argument to mana_hwc_handle_resp(). Also confirm that the system has booted into the patched kernel, not merely installed it. Exposure can be checked by determining whether the MANA driver is present or loaded and whether the system is using MANA-backed network interfaces; systems without the affected driver path are not directly exposed to this flaw.

Typical attack path

1. Gain the ability to influence the MANA device or host-controlled DMA-coherent memory visible to the guest, such as through a malicious or compromised virtualization layer, device model, or hardware path.
2. Trigger or wait for the Linux guest to receive and process a MANA hardware communication response.
3. Provide a valid hwc_msg_id value for the driver’s initial bounds check.
4. Modify the same DMA-backed hwc_msg_id field before the driver re-reads it in the response handler.
5. Cause the driver to use the attacker-controlled second value for bit testing or pointer arithmetic.
6. Leverage the resulting out-of-bounds access or memory corruption to crash the guest kernel or attempt privilege escalation/code execution in kernel context.

How to detect it

There is no reliable single log artifact that proves exploitation, and successful kernel memory corruption may leave little or no forensic evidence. Review kernel logs, persistent journald logs, crash dumps, hypervisor/cloud activity logs, and EDR telemetry for unexpected kernel oops, panic, general protection fault, invalid memory access, or reboot events involving the MANA driver. Pay particular attention to call traces referencing mana_hwc_rx_event_handler() or mana_hwc_handle_resp(), crashes occurring during network activity on MANA-backed interfaces, unexplained VM resets, and any signs of host, hypervisor, device-model, or management-plane compromise around the same time. If crash dumps are available, analyze whether the faulting stack includes the MANA hardware communication receive path and whether memory corruption appears adjacent to MANA response-context structures.

• mana_hwc_rx_event_handler
• mana_hwc_handle_resp
• Microsoft Azure Network Adapter
• MANA
• BUG: kernel NULL pointer dereference
• general protection fault
• Kernel panic - not syncing
• Call Trace:
• Oops:
• RIP: 0010:mana_hwc_rx_event_handler
• RIP: 0010:mana_hwc_handle_resp

What your security team should do

• Prioritize patching Linux systems that run on platforms exposing the MANA network driver, especially cloud or confidential VM workloads.
• Track Linux distribution and cloud provider advisories for the exact fixed kernel package versions and maintenance guidance.
• After patching, reboot systems and verify the active running kernel is the fixed kernel.
• Inventory systems with loaded or available MANA driver support and prioritize them ahead of systems that do not use the driver.
• Monitor kernel logs for MANA-related crashes, kernel oops events, general protection faults, or unexpected VM resets until patching is complete.
• Because exploitation requires control over DMA-visible device or host-side behavior, review cloud host, hypervisor, and device-management trust boundaries and investigate any concurrent signs of host compromise.
• Do not rely on EPSS alone for prioritization; the current EPSS is low and no exploit maturity is reported, but the technical impact is high where the affected driver path is reachable.