Look up another CVE · open CVE-2026-64018 in the interactive tracker
CVE-2026-64018
net: mana: validate rx_req_idx to prevent out-of-bounds array access
Published 2026-07-19 (3 months ago) by the Linux kernel CNA. Subsystem drivers/net. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-64018 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixed | 6.1.176-1 | Update the kernel and reboot. Fixed in 6.1.176-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixed | 6.12.94-1 | Update the kernel and reboot. Fixed in 6.12.94-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.0.12-1 | Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.0.12-1 | Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
In mana_hwc_rx_event_handler(), rx_req_idx is derived from sge->address in DMA-coherent memory. In Confidential VMs (SEV-SNP/TDX), this memory is shared unencrypted and HW can modify WQE contents at any time. No bounds check exists on rx_req_idx, which can lead to an out-of-bounds access into reqs[]. Add bounds check on rx_req_idx in mana_hwc_rx_event_handler() before using it to index the reqs[] array.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/net/ethernet/microsoft/mana/hw_channel.c
- What this is
- Hyper-V/Azure CORE AND DRIVERSMAINTAINERS section matched on drivers/net/ethernet/microsoft/ · linux-hyperv@vger.kernel.org · Supported
- Kernel module
- mana
Check it on the machine
grep -wE 'CONFIG_ETHERNET|CONFIG_MICROSOFT_MANA|CONFIG_NET_VENDOR_MICROSOFT' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w manaPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookwormMnot built on armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, i386/686, i386/686-pae, i386/rt/686-pae, ppc64el/powerpc64le
- trixieMnot built on armel/rpi, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- forky, sidMnot built on armhf/armmp, armhf/armmp-lpae, loong64/loong64, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- M
- a module where it is built at all; some flavours do not build it
- Build switches
- CONFIG_ETHERNET, CONFIG_MICROSOFT_MANA, CONFIG_NET_VENDOR_MICROSOFT
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-07-19 (3 months ago)source
- CVSS
- 9.3 critical
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.14%, higher than 3.1% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- drivers/net
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 5.13 | 5.15.209 | 5ddc715324ba |
| 5.13 | 6.1.175 | ff1d5af207bc |
| 5.13 | 6.6.142 | 01f7f893d5e1 |
| 5.13 | 6.12.92 | 763a372d344f |
| 5.13 | 6.18.34 | fa627a5eaa83 |
| 5.13 | 7.0.11 | 355e9f2b2a78 |
| 5.13 | 7.1 | b809d0409991 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The bug is reached via MSI-driven hardware completion processing in the MANA HWC control path (not netdev packet receive), triggered when the Azure hypervisor/host tampers with guest-visible DMA-coherent WQE memory on the same physical compute node.
- AC:LAttack complexity, low
- A malicious host or NIC firmware that can modify shared unencrypted DMA buffers controls both the forged sge->address and the timing of HWC RX completions, allowing reliable out-of-bounds indexing without winning a race or depending on guest state.
- PR:NPrivileges required, none
- Exploitation requires no privileges on the victim guest VM; the attacker operates from the Azure hypervisor/host side by modifying DMA-coherent memory that the guest kernel trusts during HWC response handling.
- UI:NUser interaction, none
- No victim user action is required; exploitation occurs automatically when the driver processes a hardware completion event on the HWC receive queue.
- S:CScope, changed
- In Confidential VMs the guest relies on host isolation guarantees, but shared unencrypted DMA memory lets a hostile hypervisor cross that CVM security boundary to corrupt guest kernel memory and confidentiality.
- C:HConfidentiality impact, high
- An out-of-bounds rx_req_idx yields a corrupted hwc_work_request whose buf_va is dereferenced and copied via memcpy in mana_hwc_handle_resp(), enabling arbitrary kernel memory disclosure.
- I:HIntegrity impact, high
- The out-of-bounds hwc_work_request supplies attacker-controlled pointers and SGE fields used to repost RX WQEs via mana_hwc_post_rx_wqe(), enabling kernel heap corruption and exploitable memory writes.
- A:HAvailability impact, high
- Indexing reqs[] out of bounds with attacker-controlled values can dereference invalid kernel pointers and corrupt adjacent heap objects, causing kernel oops/panic and denial of service.