Description
In the Linux kernel, the following vulnerability has been resolved:

wifi: mt76: mt7615: avoid waiting for mac work under the mt76 mutex

mt7615_suspend() acquired the mt76 mutex and then called
cancel_delayed_work_sync() on mac_work. mt7615_mac_work() acquires the
same mutex via mt7615_mutex_acquire() at the top of the worker, so if
mac_work is already running and blocked on the mutex, the suspend path
deadlocks waiting for the work it holds the mutex against.

Flush scan_work and mac_work before taking the mutex, matching the
suspend paths in mt7921 and mt7925. scan_work only takes the mt76
spinlock, but moving it keeps the sequence consistent. This also keeps
mac_work from running over an already suspended HIF, which the previous
split (async cancel under the lock, sync cancel after release) would
have allowed.
Published: 2026-09-11
Score: 4.4 Medium
EPSS: < 1% Very Low
KEV: No
Impact: Denial of Service via Driver Deadlock
Action: Apply Patch
AI Analysis

Impact

The kernel Wi‑Fi driver mt76 for the MT7615 device contains a deadlock that occurs during the suspend process. The suspend routine acquires the mt76 mutex and then attempts to cancel a scheduled mac_work operation. That mac_work function also tries to acquire the same mutex, so if it is already running it blocks the suspend code, which in turn waits on the mutex. The result is a permanent blocking state that effectively freezes the system or prevents it from suspending, causing a denial of service. This flaw is a classic race condition that leads to a deadlock scenario.

Affected Systems

The bug affects systems running Linux kernels that include the mt76 Wi‑Fi driver for MT7615 hardware. It is not limited to a specific kernel version but the patch that fixes the issue appears in the upstream stable tree and is referenced by several commits. Other variants such as mt7921 and mt7925 have similar logic but the defensive sequence is already in those code paths.

Risk and Exploitability

Because the vulnerability only manifests during suspend when the driver is active, exploitation would require conditions that trigger a suspend event. Based on the description, it is inferred that local privileged access may be needed to force a suspend or a power‑management event. This scenario is not explicitly documented in the public description. The EPSS score is reported as less than 1% and the issue is not listed in the CISA KEV catalog, indicating a low probability of exploitation. The flaw can cause the system to become unresponsive until a reboot, and the corrective action is to ensure the driver code incorporates the described fix.

Generated by OpenCVE AI on September 21, 2026 at 04:03 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Upgrade the system kernel to a version that includes the mt76/mt7615 driver fixes that eliminate the deadlock.
  • Reboot the system after the kernel upgrade to ensure the updated driver module is loaded.
  • If a kernel upgrade cannot be performed immediately, disable Wi‑Fi interfaces or prevent suspend events until the driver is patched to avoid triggering the deadlock.

Generated by OpenCVE AI on September 21, 2026 at 04:03 UTC.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Debian DSA Debian DSA DSA-6528-1 linux security update
History

Mon, 14 Sep 2026 12:30:00 +0000


Sat, 12 Sep 2026 12:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-833
References
Metrics threat_severity

None

cvssV3_1

{'score': 4.4, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:N/I:N/A:H'}

threat_severity

Important


Fri, 11 Sep 2026 23:45:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7615: avoid waiting for mac work under the mt76 mutex mt7615_suspend() acquired the mt76 mutex and then called cancel_delayed_work_sync() on mac_work. mt7615_mac_work() acquires the same mutex via mt7615_mutex_acquire() at the top of the worker, so if mac_work is already running and blocked on the mutex, the suspend path deadlocks waiting for the work it holds the mutex against. Flush scan_work and mac_work before taking the mutex, matching the suspend paths in mt7921 and mt7925. scan_work only takes the mt76 spinlock, but moving it keeps the sequence consistent. This also keeps mac_work from running over an already suspended HIF, which the previous split (async cancel under the lock, sync cancel after release) would have allowed.
Title wifi: mt76: mt7615: avoid waiting for mac work under the mt76 mutex
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-09-14T11:59:02.208Z

Reserved: 2026-08-26T14:34:25.803Z

Link: CVE-2026-80938

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-11T20:18:58.053

Modified: 2026-09-14T13:18:49.910

Link: CVE-2026-80938

cve-icon Redhat

Severity : Important

Publid Date: 2026-09-11T19:42:11Z

Links: CVE-2026-80938 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-09-21T04:15:08Z

Weaknesses