Linux Kernel mt76 EUVD-2026-82040

Requires a system running the Linux kernel MediaTek mt76/mt7921e Wi-Fi driver (mt7921e PCIe adapter) AND the occurrence of a PCIe AER error that hangs the bus, causing register reads to return 0xFFFFFFFF. The crash path is entered through the driver's MAC-reset recovery (mt7921_mac_reset_work → mt7921e_mac_reset → mt7921_wpdma_reset → mt76_dma_rx_reset). Key limiting factors: the trigger is a physical/hardware PCIe fault condition, not a software-controllable input, so there is no described attacker-controlled or remote/adjacent path to induce it on demand; exploitation is confined to the local machine and to the specific mt7921e PCIe deployment. This is fundamentally a fault-tolerance failure, and the description notes affected devices may not recover even after the fix due to hardware limitations.

This is a robustness/reliability fix in the Linux kernel MediaTek mt76/mt7921e Wi-Fi driver, not an attacker-driven memory-corruption vulnerability. The root cause is a PCIe Advanced Error Reporting (AER) event: when the PCIe bus hangs, register reads return 0xFFFFFFFF, and that value is used as a DMA queue index, corrupting q->head/q->tail and causing an out-of-bounds access to q->desc[]/q->entry[] (kernel paging-request oops in mt76_dma_add_buf, reached via the mt7921 MAC reset path). The vendor CVSS of 8.8 with AV:A/AC:L/PR:N/UI:N/C:H/I:H/A:H is significantly overstated and internally inconsistent with the description: the trigger is a hardware fault (bus hang from a PCIe error), NOT an adjacent-network attacker action, so AV:A is not justified, and there is no confidentiality/integrity primitive described - the observable outcome is a crash (DoS). The description itself even notes the device may not fully recover due to hardware limits (no reset pin, no re-probe), underscoring this is fault-tolerance hardening. No EPSS score, no CISA KEV listing, and no public exploit are present in the input; exploitation status is 'no public exploit identified at time of analysis.' Realistic priority is LOW: there is no clear remote/adjacent attacker path to induce the AER condition on demand, and the impact is limited to a local crash. My independent assessment lands around 3.5-4.0. Note the CVSS vector claims adjacent-network attacker impact while the description clearly implies a local PCIe hardware error condition - this discrepancy should be verified with the vendor.

A PCIe AER (bus) error occurs on a system with a MediaTek mt7921e Wi-Fi adapter; register reads begin returning 0xFFFFFFFF, which is consumed as a DMA queue index during the driver's MAC-reset recovery path, causing an out-of-bounds descriptor access and a kernel crash (denial of service). No public exploit exists, and there is no described mechanism for a network or adjacent attacker to reliably induce the underlying PCIe bus-hung condition on demand - it is primarily a fault-tolerance failure rather than a controllable attack.