Linux Kernel mt7925 EUVD-2026-38971

Exploitation requires: (1) physical or logical local access to the target system with at minimum low-privilege credentials (PR:L per CVSS vector); (2) the target system must have a MediaTek MT7925 WiFi adapter present and the mt7925 kernel driver loaded; (3) the vulnerable kernel version must be running (post-commit 45064d19fd3af6aeb0887b35b5564927980cf150, pre-fix commit for the applicable stable branch); (4) a race condition must be satisfied - roc_work() must be actively running and holding dev->mt76.mutex at the moment mt7925_roc_abort_sync() is called via the station removal path. Remote exploitation is not possible (AV:L). The non-default hardware requirement (MediaTek MT7925 adapter) and race-condition timing both limit practical exploitability beyond the already-low EPSS signal.

Real-world risk is moderate-to-low despite a CVSS base score of 5.5. The CVSS vector (AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) correctly reflects that exploitation is strictly local and requires low-privilege access - an attacker cannot exploit this remotely. EPSS at 0.17% (6th percentile) indicates extremely low observed or predicted exploitation activity, consistent with the hardware-specific and timing-sensitive nature of the flaw. The vulnerability is not listed in CISA KEV. The tags provided include 'Information Disclosure,' which appears erroneous: the CVSS vector (C:N/I:N/A:H) and description both confirm this is an availability-only, deadlock-class defect with no confidentiality impact - analysts should disregard the Information Disclosure tag. The key limiting factor is hardware: only systems with the MediaTek MT7925 WiFi adapter are affected, substantially narrowing the realistic attack surface compared to a generic Linux kernel vulnerability.

A local user with standard (low-privilege) credentials on a laptop equipped with a MediaTek MT7925 WiFi adapter initiates a wireless station removal operation - for example, by disconnecting from a network or running association management tools - at a moment when roc_work() is active and holding the mt76 mutex. The cancel_work_sync() call in mt7925_roc_abort_sync() then blocks waiting for roc_work() to release the mutex, while roc_work() cannot release it because the calling context already holds it, permanently hanging the WiFi subsystem. No public exploit code has been identified; reliably triggering the race condition likely requires precise timing or a scripted loop.