CVE-2026-64018

What it actually does

This Linux kernel flaw is an out-of-bounds array access in the Microsoft Azure Network Adapter (MANA) hardware channel receive event path. The vulnerable function derives rx_req_idx from data in DMA-coherent shared memory and uses it to index the reqs[] array without validating that the index is within bounds. In confidential VM configurations such as SEV-SNP or TDX, that DMA memory is shared unencrypted with the device/host side, so a malicious or compromised hardware, device emulation, or host-side component could alter work queue contents and cause the guest kernel to access memory outside the intended array. Depending on memory layout and exploit reliability, impact can include kernel crash, memory corruption, information disclosure, privilege boundary violation, or guest kernel compromise.

Why it matters to the business

Systems using affected Linux kernels with the MANA network driver, particularly confidential virtual machines in cloud environments, may be exposed to a high-impact guest-kernel memory corruption condition. Successful exploitation could interrupt workloads through kernel panics, undermine confidentiality guarantees expected from confidential computing deployments, or enable deeper compromise of affected virtual machines. Although EPSS is currently low and no known exploited status is reported, the high CVSS score and the cloud/confidential-computing boundary make this important to remediate during normal kernel patch cycles, with higher urgency for production confidential VMs using MANA networking.

How an attack unfolds

An attacker must be in a position to influence the MANA receive work queue data visible to the guest kernel, such as through compromised device-side logic, malicious device emulation, or a hostile lower virtualization layer able to alter DMA-coherent shared memory. The attacker modifies the address-derived value that the kernel later interprets as rx_req_idx. When the guest receives a MANA hardware channel event, mana_hwc_rx_event_handler() processes the entry and uses the untrusted rx_req_idx value to access reqs[] without first checking that the value is in range. An out-of-range index causes the kernel to read or write outside the intended request array. The immediate result may be a kernel oops or panic; with careful shaping of memory layout and event timing, the same primitive may be used to corrupt kernel memory or expose sensitive data inside the guest.

How to fix it

Upgrade to a Linux kernel build from the relevant distribution or vendor that includes the MANA driver fix adding bounds validation for rx_req_idx in mana_hwc_rx_event_handler(). No exact fixed package versions were provided in the input, so use vendor advisories and kernel changelogs to identify the first fixed release for each distribution. Prioritize systems running Microsoft Azure Network Adapter/MANA, especially confidential VM deployments using SEV-SNP or TDX. Where immediate patching is not possible, consider reducing exposure by moving critical workloads to a patched kernel, disabling or avoiding the MANA driver where operationally feasible, using an alternative supported network path, or disabling accelerated/MANA networking only if validated with the cloud/platform provider and acceptable for availability and performance. Because this is kernel memory corruption, mitigations should be treated as temporary and not equivalent to patching.

How to confirm the fix worked

Confirm the running kernel includes the upstream or vendor backport that validates rx_req_idx before indexing reqs[] in mana_hwc_rx_event_handler(). On Linux hosts, inventory MANA usage with commands such as lsmod | grep '^mana', modinfo mana, ethtool -i <interface>, and lspci where applicable. Check the running kernel version with uname -r and compare it against the distribution’s fixed kernel advisory. If source or debug packages are available, verify the MANA driver code path in drivers/net/ethernet/microsoft/mana/hw_channel.c contains an explicit bounds check for rx_req_idx before reqs[] access. After patching and rebooting into the fixed kernel, verify the active kernel version changed, the MANA module was rebuilt or replaced, and no older vulnerable kernel remains selected as the default boot option.

Typical attack path

1. Identify a target Linux system or confidential VM using the MANA network driver.
2. Gain the ability to influence MANA device/DMA-visible work queue contents, typically from a compromised or malicious device, host-side component, or virtualization layer.
3. Modify the shared work queue entry so the value used to derive rx_req_idx falls outside the valid reqs[] bounds.
4. Trigger or wait for a receive event that causes mana_hwc_rx_event_handler() to process the crafted entry.
5. Cause an out-of-bounds access in the guest kernel, leading to crash, memory disclosure, or memory corruption.
6. Optionally iterate with controlled timing and heap/layout grooming to improve reliability or pursue guest-kernel compromise.

How to detect it

Reliable post-exploitation detection is difficult because successful exploitation occurs inside kernel memory handling and may leave only crash or instability artifacts. Review kernel logs from journald, dmesg, syslog, kern.log, console logs, hypervisor/cloud serial console output, and crash dump infrastructure for faults involving the MANA driver or mana_hwc_rx_event_handler(). Look for kernel oops, panic, KASAN/KFENCE reports, slab corruption, general protection faults, page faults, or call traces referencing drivers/net/ethernet/microsoft/mana/hw_channel.c. On systems with kdump enabled, preserve and analyze vmcore files for instruction pointers, stack traces, and corrupted objects around the MANA hardware channel receive path. Correlate suspicious crashes with network receive activity, interface resets, MANA driver reloads, or changes in confidential VM host/device behavior. Absence of these artifacts does not prove absence of exploitation, especially if an attacker achieved controlled memory corruption without crashing the guest.

• mana_hwc_rx_event_handler
• drivers/net/ethernet/microsoft/mana/hw_channel.c
• BUG: KASAN:
• KFENCE:
• general protection fault
• kernel BUG at drivers/net/ethernet/microsoft/mana
• Oops:
• Kernel panic - not syncing
• Call Trace:
• mana_hwc
• mana:
• Microsoft Azure Network Adapter

What your security team should do

• Inventory Linux systems and virtual machines using the MANA network driver, with special focus on confidential VM workloads using SEV-SNP or TDX.
• Prioritize kernel updates for exposed MANA-enabled systems even though public exploit maturity is currently reported as none and EPSS is low.
• Track distribution and cloud-provider advisories for the first fixed kernel package because exact fixed versions were not provided.
• Reboot systems after kernel updates and verify they are running the fixed kernel, not merely that packages are installed.
• For high-sensitivity confidential-computing workloads, evaluate whether temporary migration to patched hosts/images or non-vulnerable network configurations is needed until patching is complete.
• Enable kernel crash dump collection and preserve vmcores for any unexplained MANA-related kernel oops or panic before patch deployment.
• Hunt historical logs for MANA driver faults, KASAN reports, out-of-bounds messages, general protection faults, and kernel panics involving mana_hwc_rx_event_handler().