Look up another CVE · open CVE-2026-90379 in the interactive tracker

CVE-2026-90379

wifi: mt76: mt7921: Add PCIe AER handler support to prevent system crash

8.8 EPSS 0.4% AV:A

Published 2026-09-17 (31 days 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-90379 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	vulnerable	6.1.190-1	No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication.
Debian 13trixie	vulnerable	6.12.113-1	No fix published anywhere yet, neither in Debian nor upstream for the series trixie tracks. Watch the Debian tracker page for this CVE. Advisories for trixie have historically landed a median of 11 days after publication.
Debian 14forky	fixed	7.2.6-1	Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts.
Debian unstablesid	fixed	7.2.6-1	Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts.

The vulnerability

What the bug is

When an AER error occurs and the bus is hung, the register reads return 0xFFFFFFFF, causing the DMA queue state to be corrupted and resulting in an invalid memory access when accessing q->desc[] or q->entry[]. Unable to handle kernel paging request at virtual address ffffffc01099eac0 pc : mt76_dma_add_buf+0x124/0x188 [mt76] lr : mt76_dma_rx_fill+0x11c/0x1d8 [mt76] sp : ffffffc016d9bbf0 x29: ffffffc016d9bc10 x28: 0000000000000000 x27: 0000000000000000 x26: ffffffb7855e50b8 x25: ffffffb80d04f000 x24: 0000000000000000 x23: 0000000000000ec0 x22: ffffffb796803648 x21: ffffffb796801f80 x20: ffffffb7968035f8 x19: 0000000000000ec0 x18: 0000000000000000 x17: 000000004ec00000 x16: 000000000ec00000 x15: ffffffc01099eac0 x14: 000000004ec00000 x13: 00000000ffc5a000 x12: ffffffc016d9bc32 x11: 00000000ffffffff x10: 0000000000000002 x9 : 0000000000000000 x8 : 000000000000b4ac x7 : 0000000000000a20 x6 : ffffffb6c1806400 x5 : 0000000000000000 x4 : ffffffb80d04f000 x3 : 0000000000000000 x2 : 0000000000000001 x1 : 000000000ec04000 x0 : ffffffb7968035f8 Call trace: mt76_dma_add_buf+0x124/0x188 [mt76 (HASH:1029 4)] mt76_dma_rx_reset+0xe8/0xfc [mt76 (HASH:1029 4)] mt7921_wpdma_reset+0x188/0x1b0 [mt7921e (HASH:ee48 5)] mt7921e_mac_reset+0x128/0x418 [mt7921e (HASH:ee48 5)] mt7921_mac_reset_work+0xac/0x1a8 [mt7921_common (HASH:f721 6)] process_one_work+0x188/0x514 worker_thread+0x12c/0x300 kthread+0x140/0x1fc ret_from_fork+0x10/0x30 Fix the invalid memory access by validating the DMA index read from the hardware before it is used as a queue index. An out-of-range value, such as the 0xFFFFFFFF returned while the bus is hung, is now clamped so it can no longer corrupt q->head or q->tail. In addition, check the bus_hung flag in mt7921_mac_reset_work() before attempting the reset sequence, reject MCU messages while the bus is hung, and install no-op bus operations when an unrecoverable AER error is detected, preventing further invalid hardware accesses. Due to hardware limitations - such as the lack of a connected hardware reset pin or the absence of host re-probe functionality - affected Wi-Fi devices may not fully recover to a normal operational state after certain errors, even with AER enabled.

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/wireless/mediatek/mt76/dma.c
drivers/net/wireless/mediatek/mt76/mcu.c
drivers/net/wireless/mediatek/mt76/mt76_connac.h
drivers/net/wireless/mediatek/mt76/mt7921/mac.c
drivers/net/wireless/mediatek/mt76/mt7921/pci.c

What this is: MEDIATEK MT76 WIRELESS LAN DRIVERMAINTAINERS section matched on drivers/net/wireless/mediatek/mt76/ · linux-wireless@vger.kernel.org · Maintained
Kernel module: mt76

Check it on the machine

grep -wE 'CONFIG_MT76_CORE|CONFIG_WLAN|CONFIG_WLAN_VENDOR_MEDIATEK' /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 mt76

Prints 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 amd64/cloud-amd64, arm64/cloud-arm64
trixie, forky, sidMnot built on amd64/cloud-amd64, arm64/cloud-arm64, s390x/s390x

M: a module where it is built at all; some flavours do not build it

Build switches: CONFIG_MT76_CORE, CONFIG_WLAN, CONFIG_WLAN_VENDOR_MEDIATEK
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

Debian tracker CVE record NVD kernel CNA record

Signals

Published: 2026-09-17 (31 days ago)source
CVSS: 8.8 high
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Hsource recompute it
Attack vector: adjacent network (AV:A)source
EPSS: 0.38%, higher than 29.9% 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
4.16	6.18.52	670b3dc4e371
4.16	7.2.6	f544bcba4721
4.16	7.3	915672c5ae32

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:AAttack vector, adjacent network: mt76_dma_sync_idx() sets q->head from Q_READ(q, dma_idx) (readl of the mt7921 PCIe DMA ring). A hung endpoint returns 0xFFFFFFFF, truncated to u16 0xFFFF. That register is the wireless DMA engine index; PCIe AER/completion-timeout on this WiFi adapter is an adjacent-radio event, not a parsed routable packet, so the vector is Adjacent.
AC:LAttack complexity, low: Once dma_idx reads 0xFFFFFFFF, mt76_dma_sync_idx() stores 0xFFFF in q->head with no bounds check, and mt76_dma_rx_reset() then calls mt76_dma_rx_fill() which indexes q->desc[]/q->entry[] at that value. MCU timeout in mt7921_mcu_parse_response() queues mt792x_reset() automatically when the hung device stops completing commands; no race is required.
PR:NPrivileges required, none: mt7921_mcu_parse_response() queues reset on MCU timeout and mt7921_mac_reset_work() runs mt7921e_mac_reset() with no capability, credential, or association check. An adjacent attacker who hangs the mt7921 endpoint needs no host account; the 0600 chip_reset debugfs file is not on this path.
UI:NUser interaction, none: mt7921_mac_reset_work() is scheduled onto the mt76 workqueue by mt792x_reset() after an MCU timeout; the OOB then occurs in kernel context during mt76_dma_rx_reset(). No victim mount, file open, or other interactive action is required beyond the interface being up.
S:UScope, unchanged: The out-of-bounds stores in mt76_dma_add_buf()/mt76_dma_add_rx_buf() target host kernel q->desc[] and q->entry[] allocated by dmam_alloc_coherent/devm_kzalloc. This stays inside the kernel's own authority and does not bypass a VM, IOMMU, or sandbox boundary.
C:HConfidentiality impact, high: q->head is a u16 loaded from the hung-bus dma_idx (0xFFFF) while MT7921_RX_RING_SIZE is 1536, so mt76_dma_add_rx_buf() reads q->entry[0xFFFF] and q->desc[0xFFFF] far past the allocated arrays. That out-of-bounds access of kernel DMA-descriptor and queue-entry memory is High confidentiality per OOB guidance.
I:HIntegrity impact, high: mt76_dma_add_buf() WRITE_ONCE-stores buf0/buf1/ctrl/info into q->desc[0xFFFF] and writes dma_addr/len into q->entry[0xFFFF], then leaves q->tail at 0xFFFF so later dequeue continues the same out-of-bounds writes. An out-of-bounds write of kernel DMA state is High integrity.
A:HAvailability impact, high: The in-tree crash is a kernel paging request at mt76_dma_add_buf() called from mt76_dma_rx_fill() during mt76_dma_rx_reset() on the mt7921e_mac_reset <- mt7921_mac_reset_work path, which oopses/panics the host (High availability).