CVE-2026-53101: Linux kernel · wifi: mt76: mt7921: fix potential deadlock in mt7921_roc_abort_sync
Source GCVE Database
Not known to be exploited · CVSS 5.5 Medium.
Data as of 26 Oct 2026, 14:05 UTC
- EPSS
- 0.1% chance of exploitation in 30 days – higher than 2% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HExploitation evidence
Disclosed: evidence found.
CVE published 24 Jun 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
AI-suggested
A fix has been implemented in the Linux kernel to prevent the mutex deadlock in the mt7921 wireless driver. Users should apply the official kernel updates that include this fix. Since this is a kernel-level issue, upgrading to a patched kernel version is the recommended remediation. Patch status is not explicitly confirmed in the provided data; users should consult the vendor or Linux kernel advisory for the exact fixed versions and update guidance.
Description
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921: fix potential deadlock in mt7921_roc_abort_sync roc_abort_sync() can deadlock with roc_work(). roc_work() holds dev->mt76.mutex, while cancel_work_sync() waits for roc_work() to finish. If the caller already owns the same mutex, both sides block and no progress is possible. This deadlock can occur during station removal when mt76_sta_state() -> mt76_sta_remove() -> mt7921_mac_sta_remove() -> mt7921_roc_abort_sync() invokes cancel_work_sync() while roc_work() is still running and holding dev->mt76.mutex. This avoids the mutex deadlock and preserves exactly-once work ownership.
References
- nvd.nist.gov/vuln/detail/CVE-2026-53101 (opens in a new tab)
- git.kernel.org/stable/c/35180c772f5e11e2fa4d80d3dfd50906cb6d9646 (opens in a new tab)
- git.kernel.org/stable/c/91e77840bf13de3add125060cf8b32ca24a52c8c (opens in a new tab)
- git.kernel.org/stable/c/b4faaa617af3f4173e64169b0ec1af8f9c5bca10 (opens in a new tab)
- git.kernel.org/stable/c/d5059e52fd8bc624ec4255c9fa01a266513d126b (opens in a new tab)