CVE-2026-53098: wifi: mt76: mt7915: fix use-after-free bugs in mt7915_mac_dump_work()
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7915: fix use-after-free bugs in mt7915macdumpwork()
When the mt7915 pci chip is detaching, the mt7915crashdata is released in mt7915coredumpunregister(). However, the work item dumpwork may still be running or pending, leading to UAF bugs when the already freed crashdata is dereferenced again in mt7915macdumpwork().
The race condition can occur as follows:
CPU 0 (removal path) | CPU 1 (workqueue) mt7915pciremove() | mt7915sysrecoveryset() mt7915unregisterdevice() | mt7915reset() mt7915coredumpunregister() | queuework() vfree(dev->coredump.crashdata) | mt7915macdumpwork() | crashdata-> // UAF
Fix this by ensuring dumpwork is properly canceled before the crashdata is deallocated. Add cancelworksync() in mt7915unregisterdevice() to synchronize with any pending or executing dump work.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Ensure mt7915_coredump_unregister() synchronizes with any pending or executing dump_work so mt7915_mac_dump_work() cannot dereference freed crash_data. Concretely, cancel/dismount dump_work via cancel_work_sync() (removal path) before releasing/deallocating mt7915_crash_data (e.g., before vfree(dev->coredump.crash_data) during mt7915_coredump_unregister()).
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel mt76/mt7915 Wi-Fi driver are affected when an mt7915 PCI device is detached while its crash-dump work item can still run or remain pending.
What conditions are needed to trigger the use-after-free?
The race requires a device-removal path to free mt7915 crash data while the dump_work workqueue item is queued or executing. The vulnerable path dereferences the freed crash_data in mt7915_mac_dump_work().
Is this remotely exploitable?
The supplied CVSS vector identifies local access, low attack complexity, low privileges, and no user interaction as the attack conditions. It does not indicate a network-based attack vector.
What is the remediation?
Apply a kernel update containing the fix that cancels and synchronizes dump_work with cancel_work_sync() in mt7915_unregister_device() before crash_data is deallocated.