CVE-2026-53103

What it actually does

This is a Linux kernel denial-of-service flaw in the MediaTek mt76 mt7925 Wi-Fi driver. A race/deadlock can occur when mt7925_roc_abort_sync() calls cancel_work_sync() while related remain-on-channel work is still running and holding dev->mt76.mutex. If station removal occurs while this work item owns the mutex and the caller also needs the same mutex, both execution paths can block indefinitely. The practical technical result is a hung kernel worker or blocked wireless driver path, potentially causing Wi-Fi disruption, stalled network teardown/removal operations, and in some cases broader system unresponsiveness depending on what kernel tasks are blocked.

Why it matters to the business

Systems using affected Linux kernels with MediaTek MT7925 Wi-Fi hardware may experience wireless outages or hangs during disconnect, roaming, station removal, or similar Wi-Fi state changes. For laptops, workstations, embedded Linux devices, kiosks, and appliances that rely on this chipset, the impact is primarily loss of availability and operational disruption rather than data theft or remote code execution. The issue is not currently in CISA KEV, is not associated with ransomware use, has no known public exploit maturity in the provided data, and has a very low EPSS score, so remediation should be prioritized for exposed or operationally critical Linux endpoints using this driver rather than treated as an internet-wide emergency.

How an attack unfolds

An attacker would need conditions that cause an affected system to exercise the mt7925 Wi-Fi station removal path while roc_work is active. In a realistic scenario, this could involve repeatedly forcing or inducing Wi-Fi disconnects, association changes, roaming events, or channel-related operations against a system using the vulnerable mt7925 driver. If the timing aligns, roc_work holds the mt76 device mutex while mt7925_roc_abort_sync() waits for that work to finish through cancel_work_sync(), producing a circular wait. Once the deadlock occurs, wireless operations may stop progressing and the affected host may require interface reset, driver reload, or reboot to recover. This is a reliability and availability issue; the provided details do not indicate arbitrary code execution, privilege escalation, credential access, or persistence.

How to fix it

Apply a Linux kernel version or vendor backport that includes the mt76/mt7925 fix for mt7925_roc_abort_sync deadlock handling. Because no exact fixed versions were provided, use the fixed kernel packages published by the relevant Linux distribution, hardware vendor, or upstream stable kernel branch. Prioritize systems that both run affected kernels and use MediaTek MT7925 Wi-Fi hardware. If immediate patching is not possible, reduce exposure by disabling the affected Wi-Fi adapter, using wired networking or an alternate adapter, avoiding untrusted Wi-Fi environments, and scheduling reboots for systems that exhibit hung wireless behavior. Operational mitigations are temporary; the durable fix is the corrected kernel driver code.

How to confirm the fix worked

Confirm that the running kernel contains the vendor or upstream fix for the mt76 mt7925 deadlock. Validate package status using the distribution package manager and compare against the distribution security advisory for this issue. Confirm exposure by checking for MediaTek MT7925 hardware and loaded mt76/mt7925 driver modules using tools such as lspci, lsusb, lsmod, modinfo, and dmesg. After patching, reboot into the fixed kernel and verify that the older vulnerable kernel is not the active boot entry. Functional validation can include controlled Wi-Fi disconnect, reconnect, roaming, suspend/resume, and interface removal testing while monitoring dmesg or journalctl for hung task, workqueue, mutex, or mt7925 driver errors.

Typical attack path

1. Identify or encounter a Linux system using the MediaTek MT7925 Wi-Fi driver in an affected kernel build.
2. Create or wait for conditions that cause remain-on-channel work and station removal or disconnect handling to overlap.
3. Trigger repeated Wi-Fi state changes such as disconnects, deauth-like events, roaming, or station teardown conditions.
4. Race the vulnerable path so roc_work holds dev->mt76.mutex while mt7925_roc_abort_sync() invokes cancel_work_sync().
5. Cause the kernel workqueue or Wi-Fi driver path to deadlock, resulting in wireless service disruption or system unresponsiveness.
6. Maintain disruption by continuing to trigger disconnect or teardown events until the system is patched or rebooted/recovered.

How to detect it

Review kernel and system logs for evidence of the vulnerable driver path hanging or wireless operations stalling. Useful sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, NetworkManager logs, wpa_supplicant logs, and crash or kdump artifacts if enabled. Look for hung task warnings, blocked workqueue threads, mutex or lockup messages, repeated mt7925/mt76 driver errors, repeated disconnect/reconnect events, and stack traces containing mt7925_roc_abort_sync, mt7925_mac_link_sta_remove, mt7925_mac_sta_remove_link, mt76_sta_remove, roc_work, or cancel_work_sync. Correlate these events with Wi-Fi disassociation, roaming, suspend/resume, or station removal activity. There are no provided reports of active exploitation, named threat actors, ransomware usage, or public exploit tooling, so detection should focus on signs the deadlock condition occurred rather than conventional post-compromise artifacts.

• mt7925_roc_abort_sync
• mt7925_mac_link_sta_remove
• mt7925_mac_sta_remove_link
• mt76_sta_remove
• roc_work
• cancel_work_sync
• dev->mt76.mutex
• mt7925
• mt76
• mt7925e
• INFO: task
• blocked for more than
• hung task
• workqueue
• task blocked
• kernel: mt7925
• kernel: mt76
• wlan0: deauthenticating
• wlan0: disassociated
• NetworkManager.*mt7925
• wpa_supplicant.*CTRL-EVENT-DISCONNECTED

What your security team should do

• Inventory Linux systems for MediaTek MT7925 Wi-Fi hardware and loaded mt76/mt7925 kernel modules.
• Map those systems to their running kernel versions and vendor security advisories to determine whether the mt7925 deadlock fix is present.
• Patch or upgrade affected systems through the normal kernel update process, prioritizing mobile, embedded, kiosk, and operationally important devices that depend on Wi-Fi connectivity.
• Reboot systems after kernel update and verify they are running the fixed kernel, not only that the package is installed.
• For systems that cannot be patched promptly, disable the affected Wi-Fi interface or move them to wired or alternate wireless hardware where operationally feasible.
• Monitor kernel logs for hung tasks, mt7925/mt76 errors, repeated Wi-Fi disconnects, and workqueue stalls that could indicate the issue has been triggered.
• Treat observed exploitation primarily as an availability incident; collect kernel logs and wireless event timelines, but do not assume compromise solely from this deadlock condition.