Bug 2532443 (CVE-2026-80938)

Summary: CVE-2026-80938 kernel: wifi: mt76: mt7615: avoid waiting for mac work under the mt76 mutex
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security <prodsec-ir-bot>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: akhatavk, aos-team-art-private, asdas, dpaolell, jdelft, jupierce, lgarciaa, mbiarnes, ppalepu, ppostler, prdhamdh, rhel-process-autobot, sghai, sidsharm, suppawar, vlaad, watson-tool-maintainers
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in the Linux kernel, specifically within the `mt7615` Wi-Fi driver. A deadlock can occur during system suspend operations when the suspend process attempts to acquire a mutex (a locking mechanism) while simultaneously waiting for a work item (`mac_work`) that also requires the same mutex. If `mac_work` is already running and blocked on the mutex, the suspend path will indefinitely wait for the work it holds the mutex against. This can result in a Denial of Service (DoS), making the system unresponsive.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-09-11 23:17:57 UTC 
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.
Comment 1 Keith Grant 2026-09-14 14:36:10 UTC 
Upstream advisory:
https://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2026/CVE-2026-80938.mbox