CVE-2026-53101

What it actually does

This is a denial-of-service flaw in the Linux kernel mt76 mt7921 Wi-Fi driver. A race between remain-on-channel abort handling and asynchronous ROC work can cause a mutex deadlock when station removal occurs while the work item is still running. The result is blocked kernel work, stalled Wi-Fi driver operations, and potentially a hung network stack or degraded host responsiveness. The flaw does not indicate memory corruption, privilege escalation, or remote code execution.

Why it matters to the business

Systems using affected MediaTek MT7921 Wi-Fi hardware may lose wireless connectivity or require a reboot to recover if the deadlock is triggered. For laptops, kiosks, mobile workstations, embedded devices, or operational systems that depend on Wi-Fi, this can cause user disruption, dropped sessions, monitoring gaps, or temporary service unavailability. The current public exploitation signal is low: EPSS is 0.00095, it is not in CISA KEV, no ransomware use is indicated, and no public exploit maturity is reported.

How an attack unfolds

An attacker must be in a position to influence Wi-Fi state changes on a system using the vulnerable mt7921 driver, or otherwise cause repeated station removal and remain-on-channel activity. In a plausible wireless-adjacent scenario, the attacker induces connection churn, disassociation, roaming, or channel-operation timing that causes station removal to call into mt7921_roc_abort_sync while roc_work is still active. If the vulnerable timing is reached, one path waits for cancel_work_sync to finish while the work item holds the same mt76 mutex, causing both sides to block indefinitely. The practical outcome is denial of service of the Wi-Fi driver or related network operations until the driver is reset or the system is rebooted.

How to fix it

Apply a Linux kernel update from the distribution, device vendor, or upstream stable kernel that includes the mt76 mt7921 deadlock fix for CVE-2026-53101. No exact fixed package versions were provided in the input, so use vendor advisories, kernel changelogs, and package metadata to identify the first fixed build for each supported platform. Where immediate patching is not possible, reduce exposure by disabling the mt7921 Wi-Fi interface, using wired networking, preventing untrusted users from manipulating Wi-Fi state, limiting use of unstable or hostile wireless networks, and rebooting or reloading the driver after any suspected deadlock. Avoid relying on service restarts alone if the kernel worker is blocked; a module reload or full reboot may be required.

How to confirm the fix worked

Confirm that the running kernel package or vendor firmware/kernel image includes the upstream mt76 mt7921 fix for the mt7921_roc_abort_sync deadlock. Validate the active kernel with uname -a and package manager queries, then compare the installed kernel build against the vendor’s fixed advisory or changelog. Confirm the mt7921 driver is present only on systems that actually need it by checking loaded modules such as mt7921e, mt7921_common, mt76_connac_lib, and mt76. After patching, exercise normal Wi-Fi connect, disconnect, roam, suspend/resume, and station-removal workflows and verify that kernel logs no longer show hung tasks or stack traces involving mt7921_roc_abort_sync, mt7921_mac_sta_remove, mt76_sta_remove, or mt7921_roc_work.

Typical attack path

1. Identify a target system using a Linux kernel with the mt76 mt7921 Wi-Fi driver and MediaTek MT7921-class wireless hardware.
2. Get into wireless range or obtain local ability to trigger Wi-Fi connect, disconnect, roaming, scanning, or station-removal events.
3. Create repeated Wi-Fi state transitions such as disassociation, reconnect attempts, channel changes, or remain-on-channel activity.
4. Race station removal against active ROC work so mt7921_roc_abort_sync calls cancel_work_sync while roc_work holds dev->mt76.mutex.
5. Cause a kernel mutex deadlock that stalls Wi-Fi driver progress.
6. Maintain disruption until the Wi-Fi stack, kernel module, network service, or host is restarted.

How to detect it

To determine whether this issue may already have been triggered, review kernel logs, system journals, crash dumps, and monitoring alerts for Wi-Fi hangs, blocked kernel tasks, watchdog soft lockups, or stack traces involving the mt76/mt7921 driver. Useful sources include journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, pstore/ramoops, kdump/vmcore analysis, and endpoint telemetry that captures kernel oops or hung-task events. Focus on events near Wi-Fi disconnects, roaming, suspend/resume, station removal, or repeated association failures. Look for call traces containing mt7921_roc_abort_sync, mt7921_roc_work, mt7921_mac_sta_remove, mt76_sta_remove, or mt76_sta_state. Because this is a deadlock rather than code execution, there may be no durable attacker-created file or process artifact; evidence is most likely to be kernel log output and timing correlation with wireless disruption.

• mt7921_roc_abort_sync
• mt7921_roc_work
• mt7921_mac_sta_remove
• mt76_sta_remove
• mt76_sta_state
• mt7921e
• mt7921_common
• mt76_connac_lib
• kernel: INFO: task
• blocked for more than
• kernel: watchdog: BUG: soft lockup
• kernel: rcu: INFO: rcu_preempt detected stalls
• workqueue:
• dev->mt76.mutex

What your security team should do

• Inventory Linux endpoints and embedded systems for MediaTek MT7921 Wi-Fi hardware and loaded mt76/mt7921 kernel modules.
• Prioritize patching systems that rely on Wi-Fi for operations, are used in public or hostile wireless environments, or cannot tolerate connectivity loss.
• Track distribution and hardware-vendor kernel advisories for the fixed kernel build because exact fixed versions were not provided.
• Deploy temporary mitigations, such as wired networking or disabling the affected Wi-Fi interface, for high-availability systems until patched.
• Add monitoring for kernel hung-task, soft-lockup, and Wi-Fi driver stack traces involving mt7921 and mt76 functions.
• Treat observed hangs as availability incidents; collect kernel logs before rebooting where possible to preserve evidence.
• Do not prioritize this as a remote-code-execution emergency absent new intelligence: it is not KEV-listed, has very low EPSS, no reported ransomware use, and no known public exploit maturity.