CVE-2026-53100

What it actually does

This vulnerability is a Linux kernel deadlock in the mt76 wireless driver family. The remain-on-channel and remain-on-channel-complete code paths call a channel-setting routine while already holding the device mutex; because that routine attempts to acquire the same mutex again, the kernel can deadlock the affected wireless device path. A secondary deadlock condition involving the mac_work workqueue is also addressed by the fix. The practical technical effect is denial of service affecting Wi-Fi driver operation and potentially broader system responsiveness if kernel worker threads or networking paths become stuck.

Why it matters to the business

Systems using affected MediaTek mt76-based Wi-Fi hardware may experience wireless connectivity loss, degraded network availability, or system instability. This is primarily an availability risk rather than a data theft or code execution issue. The current EPSS is very low, it is not listed in CISA KEV, and no public exploitation maturity is indicated, so prioritization should be based on exposure to untrusted Wi-Fi environments, reliance on wireless connectivity, and operational tolerance for outages.

How an attack unfolds

An attacker would need to cause or trigger kernel Wi-Fi operations that exercise the mt76 remain-on-channel path, such as workflows involving channel changes, scanning, management frame handling, or related wireless coordination behavior. When the vulnerable path is reached, the driver attempts to acquire a mutex it already holds, resulting in a deadlock. The deadlock can leave Wi-Fi operations stuck and may require interface reset, driver reload, or host reboot to recover. There is no indication from the provided intelligence that this flaw enables privilege escalation, remote code execution, data access, or ransomware activity.

How to fix it

Apply a Linux kernel update that includes the mt76 fix replacing nested mt76_set_channel() calls with __mt76_set_channel() in the relevant locked paths and adding cancellation of delayed mac_work before acquiring the mutex. If vendor kernels are used, install the latest distribution, appliance, or device firmware update that backports the fix. If immediate patching is not possible, reduce exposure by disabling unused mt76 Wi-Fi interfaces, avoiding reliance on affected Wi-Fi hardware for critical connectivity, using wired networking where feasible, and monitoring for recurring driver hangs. Because no fixed versions were provided, obtain the exact corrected kernel or firmware version from the Linux distribution, device vendor, or kernel stable advisory applicable to the deployed platform.

How to confirm the fix worked

Confirm that the running kernel or vendor firmware includes the mt76 deadlock fix. Validate by checking package changelogs, kernel advisory notes, or source patches for changes to mt76_remain_on_channel(), mt76_roc_complete(), __mt76_set_channel(), and cancel_delayed_work_sync() handling around mac_work. On representative hardware, perform Wi-Fi scanning, connection, roam, remain-on-channel, and suspend/resume workflows while monitoring dmesg and kernel logs for hung task warnings, mutex lockups, workqueue stalls, or mt76/mac80211 errors. Confirm that the Wi-Fi interface remains responsive and does not require driver reload or reboot under repeated testing.

Typical attack path

1. Identify a target system using an affected Linux kernel with mt76-based Wi-Fi hardware enabled.
2. Place the target in a condition where mt76 remain-on-channel behavior is exercised, such as wireless scanning, connection management, or channel coordination activity.
3. Trigger the vulnerable code path so mt76_remain_on_channel() or mt76_roc_complete() attempts to set the channel while already holding the device mutex.
4. Cause the driver path or related workqueue to deadlock.
5. Result in Wi-Fi disruption, network unavailability, or a system state requiring administrative recovery.

How to detect it

To determine whether this condition may already have occurred, review kernel logs and system journals for Wi-Fi hangs, mt76 driver messages, mac80211 errors, hung task warnings, workqueue stalls, mutex lockups, interface resets, or administrator-initiated recovery actions such as module reloads or reboots following wireless disruption. Useful sources include dmesg, journald, /var/log/kern.log, /var/log/messages, distribution crash logs, network manager logs, and endpoint telemetry capturing kernel warnings. Look for repeated occurrences around wireless scanning, roaming, connection drops, or channel-change activity. Because this is a deadlock rather than malware execution, durable file, registry, or process IOCs are not expected; detection should focus on kernel telemetry and operational symptoms. There are no known threat actors, ransomware campaigns, or public exploit artifacts identified in the provided intelligence.

• mt76
• mt76_remain_on_channel
• mt76_roc_complete
• mt76_set_channel
• __mt76_set_channel
• mac_work
• cancel_delayed_work_sync
• INFO: task
• blocked for more than
• hung_task
• workqueue lockup
• mac80211
• wlan0: deauthenticating
• wlan0: disassociated
• NetworkManager
• kernel: mt76
• kernel: mac80211

What your security team should do

• Inventory Linux systems and embedded devices using MediaTek mt76-based Wi-Fi chipsets or drivers.
• Prioritize updates for systems where Wi-Fi availability is operationally important or where devices operate in untrusted wireless environments.
• Apply vendor kernel, distribution, or firmware updates that include the mt76 remain-on-channel deadlock fix.
• Where patching is delayed, prefer wired connectivity, disable unnecessary affected Wi-Fi interfaces, and establish reboot or driver-reload recovery procedures.
• Monitor kernel logs for mt76, mac80211, workqueue, mutex, and hung-task messages indicating possible exploitation or recurrence.
• Track distribution advisories for exact fixed kernel versions because affected product and fixed-version details were not provided in the input.
• Treat this as an availability issue with low current exploitation likelihood, but include it in routine kernel patch cycles.