Answer in brief
CVE-2026-53101 records a Unknown severity vulnerability in wifi: mt76: mt7921: fix potential deadlock in mt7921_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 | >=352d966126e66d825244f1185eb9f2d904c83dd4 <b4faaa617af3f4173e64169b0ec1af8f9c5bca10 || >=352d966126e66d825244f1185eb9f2d904c83dd4 <35180c772f5e11e2fa4d80d3dfd50906cb6d9646 || >=352d966126e66d825244f1185eb9f2d904c83dd4 <91e77840bf13de3add125060cf8b32ca24a52c8c || >=352d966126e66d825244f1185eb9f2d904c83dd4 <d5059e52fd8bc624ec4255c9fa01a266513d126b | b4faaa617af3f4173e64169b0ec1af8f9c5bca10, 35180c772f5e11e2fa4d80d3dfd50906cb6d9646, 91e77840bf13de3add125060cf8b32ca24a52c8c, d5059e52fd8bc624ec4255c9fa01a266513d126b |
| Linux/Linuxgeneric | 6.9 | Not reported |
Published upstream
Jun 24, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Nov 6, 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: 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.
Quoted source text, attributed separately from HOL analysis.