CVE-2026-80937: wifi: mt76: mt7915: bound the device EEPROM address before the EFUSE copy
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7915: bound the device EEPROM address before the EFUSE copy
mt7915mcugeteeprom() copies a fixed EFUSE block into the driver's dev->mt76.eeprom.data buffer at the offset reported by the MCU response (res->addr, a device-controlled le32) without checking it against the buffer size. A malicious or malfunctioning device can report an arbitrary address and drive a 16-byte out-of-bounds write past eeprom.data.
Reject a response whose address would place the copy outside eeprom.data before deriving the destination pointer. Devices that echo the requested in-bounds offset are unaffected.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Apply the fix so mt7915_mcu_get_eeprom() rejects MCU responses with an EEPROM address that would cause the EFUSE copy to write past the dev->mt76.eeprom.data buffer; perform the bounds check before deriving the destination pointer.
Linux kernel (mt76/mt7915) mt7915_mcu_get_eeprom device EEPROM address bounds check = Reject a response whose address would place the copy outside eeprom.data before deriving the destination pointer (bound the MCU-reported EEPROM address)
Event History
Frequently Asked Questions
What systems are realistically exposed to this issue?
Systems using the Linux kernel mt76 mt7915 Wi-Fi driver are exposed when the driver obtains EEPROM data from a device that can return a malicious or malformed MCU response. Devices that echo the requested in-bounds offset are unaffected.
What does an attacker or faulty device need to do to trigger the vulnerability?
The device must report an EEPROM address in the MCU response that causes the fixed 16-byte EFUSE block copy to extend beyond the driver's eeprom.data buffer. The reported address is device-controlled and was not validated before calculating the destination pointer.
How can I determine whether a device response is unsafe?
A response is unsafe if its reported address would place the 16-byte EFUSE copy outside eeprom.data. Responses that return the requested in-bounds offset do not trigger the issue.