Answer in brief
CVE-2026-53103 records a Unknown severity vulnerability in wifi: mt76: mt7925: fix potential deadlock in mt7925_roc_abort_sync. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=45064d19fd3af6aeb0887b35b5564927980cf150 <253cfc33d95ce4a30fd2eca0ff0138603c6c2fcc || >=45064d19fd3af6aeb0887b35b5564927980cf150 <153bcba36c87a1ba555b57b6c49028d5812f895b || >=45064d19fd3af6aeb0887b35b5564927980cf150 <2d8e0053bca29143ace51e08c980ff076844a4b0 || >=45064d19fd3af6aeb0887b35b5564927980cf150 <dd08ca3f092f4185ece69ce2a835c23198b1628a || 978d1756b3ae1b857826eb7ed8181f3c5180dce9 || >=6.11.2 <6.12 | 253cfc33d95ce4a30fd2eca0ff0138603c6c2fcc, 153bcba36c87a1ba555b57b6c49028d5812f895b, 2d8e0053bca29143ace51e08c980ff076844a4b0, dd08ca3f092f4185ece69ce2a835c23198b1628a, 6.12 |
| Linux/Linuxgeneric | 6.12 | Not reported |
Published upstream
Jun 24, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Oct 21, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Jun 24, 2026
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: fix potential deadlock in mt7925_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() -> mt7925_mac_sta_remove_link() -> mt7925_mac_link_sta_remove() -> mt7925_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.
Quoted source text, attributed separately from HOL analysis.