CVE-2026-53103: Linux Kernel Race Condition Vulnerability

CVE-2026-53103 Overview

CVE-2026-53103 is a deadlock vulnerability in the Linux kernel's mt76 wireless driver, specifically affecting the MediaTek MT7925 WiFi chipset support. The flaw exists in the mt7925_roc_abort_sync() function, which can deadlock with roc_work() during station removal operations. The deadlock occurs because roc_work() holds dev->mt76.mutex while cancel_work_sync() waits for roc_work() to complete. If the caller already owns the same mutex, both sides block indefinitely.

Critical Impact
A kernel deadlock condition can render the affected wireless subsystem unresponsive, requiring system reboot to recover. The condition is triggered during station removal in normal WiFi operation paths.

Affected Products

Linux kernel versions containing the mt76 driver with MT7925 support
Systems using MediaTek MT7925 WiFi chipsets
Distributions shipping affected upstream kernel builds prior to the fix commits

Discovery Timeline

2026-06-24 - CVE-2026-53103 published to NVD
2026-06-24 - Last updated in NVD database

Technical Details for CVE-2026-53103

Vulnerability Analysis

The vulnerability is a classic mutex-versus-work-queue deadlock [CWE-833] in the kernel's MediaTek MT7925 WiFi driver. The roc_work() function executes on a kernel workqueue and acquires dev->mt76.mutex during its execution. Separately, mt7925_roc_abort_sync() invokes cancel_work_sync() to ensure the work item finishes before continuing teardown.

When mt7925_roc_abort_sync() runs in a context that already holds dev->mt76.mutex, a circular wait condition forms. The caller cannot release the mutex until cancel_work_sync() returns, and cancel_work_sync() cannot return until roc_work() finishes, but roc_work() cannot acquire the mutex because the caller still holds it.

The EPSS score is 0.166% with a percentile of 6.208, indicating low predicted exploitation likelihood, consistent with a local stability bug rather than an externally exploitable flaw.

Root Cause

The root cause is improper synchronization design between the Remain-on-Channel (RoC) abort path and the deferred RoC work handler. Both contend for dev->mt76.mutex, but the abort path invokes cancel_work_sync() while holding the same lock the worker needs to acquire. This violates the kernel's lock-ordering requirements for synchronous work cancellation.

Attack Vector

The deadlock is triggered through the station removal code path: mt76_sta_state() → mt76_sta_remove() → mt7925_mac_sta_remove_link() → mt7925_mac_link_sta_remove() → mt7925_roc_abort_sync(). A local user or remote peer whose disassociation triggers station teardown while RoC work is pending can induce the deadlock. Exploitation requires the precise timing of station removal during an active RoC operation, making this primarily a stability and denial-of-service concern rather than a privilege escalation vector.

The upstream fix restructures the abort logic to avoid invoking cancel_work_sync() while holding dev->mt76.mutex, preserving exactly-once work ownership semantics. See the upstream kernel commits referenced below for the precise code changes.

Detection Methods for CVE-2026-53103

Indicators of Compromise

Kernel hung-task warnings referencing mt7925_roc_abort_sync or cancel_work_sync in dmesg or /var/log/kern.log
Soft lockup or task blocked for more than X seconds messages tied to mt76 worker threads
Wireless interface becoming unresponsive following station disassociation events
System processes blocked waiting on dev->mt76.mutex visible in /proc/<pid>/stack

Detection Strategies

Monitor kernel logs for hung-task or lockdep warnings involving the mt76 and mt7925 modules
Inventory systems running MediaTek MT7925 hardware and correlate kernel versions against the patched commits
Use lsmod | grep mt7925 and uname -r across the fleet to identify exposed hosts
Track wireless subsystem availability metrics for unexpected interface stalls following client disconnect events

Monitoring Recommendations

Enable CONFIG_DETECT_HUNG_TASK and CONFIG_LOCKDEP on test systems to surface deadlock conditions early
Forward kernel logs to a centralized logging or SIEM platform for pattern detection across hosts
Alert on repeated WiFi interface resets or driver reload events that may indicate users recovering from the deadlock
Baseline normal mt76 workqueue behavior so deviations are visible in telemetry

How to Mitigate CVE-2026-53103

Immediate Actions Required

Identify all systems running affected kernel versions with the mt76/mt7925 driver loaded
Apply the upstream kernel patches referenced in the Kernel Git Commit 153bcba, Kernel Git Commit 2d8e005, and Kernel Git Commit dd08ca3
Prioritize patching on systems where WiFi availability is operationally critical
Track distribution security advisories for backported fixes to stable kernel branches

Patch Information

The vulnerability is resolved upstream through three kernel commits that restructure mt7925_roc_abort_sync() to avoid invoking cancel_work_sync() while holding dev->mt76.mutex. Stable kernel maintainers have backported the fix; update to a kernel build that includes commits 153bcba, 2d8e005, or dd08ca3 as appropriate for your branch.

Workarounds

Where patching is delayed, unload the mt7925e or mt7925u module on systems that do not require WiFi: modprobe -r mt7925e
Disable Remain-on-Channel features in userspace where supported by wpa_supplicant or iw configuration
Use wired Ethernet on affected hosts until a patched kernel is deployed
Reduce station churn on access points using MT7925 hardware to lower the chance of triggering the race window

bash

# Verify whether the mt7925 driver is loaded and identify kernel version
uname -r
lsmod | grep mt7925

# Temporary workaround: unload the driver if WiFi is not required
sudo modprobe -r mt7925e

# Prevent automatic loading until kernel is patched
echo "blacklist mt7925e" | sudo tee /etc/modprobe.d/blacklist-mt7925.conf
sudo update-initramfs -u