CVE-2026-80937

What it actually does

The MediaTek mt76 mt7915 Wi-Fi driver copies a fixed 16-byte EFUSE block into the kernel EEPROM buffer using an MCU-supplied 32-bit address with no check against buffer size. A malicious or faulty radio can therefore drive a 16-byte out-of-bounds kernel write past eeprom.data, corrupting adjacent kernel memory. That write can crash the kernel (oops/panic) or, with further heap/object shaping, yield a kernel write primitive usable for privilege escalation and full ring-0 compromise. Scope is unchanged; impact is local to the host running the driver. Devices that echo the requested in-bounds offset do not trigger the bug.

Why it matters to the business

Linux systems with MediaTek MT7915-class radios—laptops, access points, CPE, OpenWrt/router appliances, and embedded devices—can be fully taken over or knocked offline by a nearby attacker or a compromised/malicious Wi-Fi chip. CVSS 8.8 (adjacent, no privileges, no user interaction, high CIA) means wireless infrastructure and any host that enumerates an untrusted MT7915 adapter are in scope. The issue is not in CISA KEV, is not tied to ransomware campaigns, has no public exploit (maturity None), and EPSS is low and flat (~0.0038 over 30 days). Twenty days after publication, urgency comes from kernel-memory-write severity and the breadth of mt76 in consumer and network gear rather than observed mass exploitation. Unpatched wireless gateways and multi-tenant APs present the highest operational risk (outage plus potential pivot).

How an attack unfolds

An attacker who controls the MT7915 MCU—via malicious or replaced hardware, unsigned/compromised radio firmware, or a device they attach over PCIe/USB—waits for the host driver to request EEPROM/EFUSE contents (typical during probe or runtime calibration). The MCU returns a response whose addr field is an arbitrary little-endian offset, not the in-bounds location the driver asked for. The unpatched mt7915_mcu_get_eeprom path uses that value as the destination into the EEPROM buffer and copies 16 bytes without verifying the range, writing past the buffer into neighboring kernel memory. The attacker then uses that corruption to panic the host or to overwrite nearby kernel objects and gain code execution in kernel context. No authentication or user click is required once the malicious device is on the bus or the firmware is loaded. Legitimate firmware that echoes the requested in-bounds offset cannot be used this way. No named threat actors or campaigns are associated with this CVE.

How to fix it

Apply the Linux kernel fix that rejects an MCU EEPROM response whose address would place the 16-byte copy outside the EEPROM buffer before the destination pointer is derived. Upgrade to a distro, LTS, Android, OpenWrt, or OEM kernel that includes the mt76 mt7915 EEPROM bounds check; no canonical upstream version numbers were supplied with this record, so confirm via vendor changelog or kernel git history for the mt7915_mcu_get_eeprom guard. Until patched, do not attach untrusted MT7915 USB/PCIe adapters, do not load unsigned or third-party radio firmware, and restrict which hosts may enumerate MediaTek Wi-Fi NICs. Compensating controls do not remove the kernel write if a malicious MCU is already present.

How to confirm the fix worked

Inventory hosts with MT7915 hardware (PCI/USB IDs, lsmod mt7915e/mt76) and compare running kernel packages against vendor advisories that mention the mt7915 EEPROM address bound. In source or disassembly, confirm mt7915_mcu_get_eeprom rejects an out-of-range MCU address before the EFUSE copy. After patching, reboot or reload the driver and verify the interface still associates; in-bounds devices are unaffected. Spot-check dmesg for clean mt76 probe without oops. Re-scan images and appliances (routers, APs, CPE) that vendor-fork the kernel rather than tracking mainline.

Typical attack path

1. Obtain adjacent or physical influence over an MT7915-class radio (malicious adapter, firmware implant, or swapped module) on a Linux host running unpatched mt76/mt7915.
2. Wait for or trigger a driver MCU EEPROM/EFUSE read during device probe, reset, or calibration.
3. Return an MCU response whose address field points outside the kernel EEPROM buffer.
4. Cause the unbounded 16-byte EFUSE copy to overwrite adjacent kernel memory.
5. Convert the out-of-bounds write into a kernel panic (denial of service) or further primitives toward kernel code execution and persistence.

How to detect it

There is no network exploit payload and no KEV/ransomware or named-actor association. Detection of prior abuse is forensic: kernel oops, panic, warning, or paging-request logs whose call traces include mt7915_mcu_get_eeprom, mt76 EEPROM handling, or mt7915e during device probe, reset, or firmware/EEPROM read. Review persistent journal/dmesg/pstore/kdump on hosts and APs with MediaTek radios for unexpected reboots coinciding with Wi-Fi bring-up or adapter attach. Note newly inserted USB/PCIe MT7915 devices and unusual radio firmware loads. Absence of oops does not prove non-exploitation if the 16-byte write corrupted memory without an immediate crash.

• mt7915_mcu_get_eeprom
• mt7915e
• mt76:
• Call Trace: mt7915
• Oops:.*mt7915
• BUG: unable to handle kernel paging request
• Kernel panic - not syncing:
• mt7915_mcu_
• eeprom.data

What your security team should do

• Inventory Linux endpoints, APs, and appliances using mt76/mt7915 and treat unpatched kernels as high priority given CVSS 8.8 kernel write impact.
• Deploy vendor/distro kernels that include the mt7915 EEPROM address bound; verify the guard is present, not only that a package version moved.
• Block untrusted MT7915 adapters and unsigned radio firmware in hardware allow-lists and secure-boot/firmware policies.
• Monitor kernel logs for mt76/mt7915 oops during probe; low EPSS and no KEV listing support a planned window if those controls are in place, not indefinite deferral.
• Track distro and OEM advisories for exact fixed kernel versions as they publish; this record does not list them.
• Prioritize internet-facing and multi-tenant wireless infrastructure over isolated lab hosts.