CVE-2026-53098

What it actually does

This is a Linux kernel use-after-free race condition in the MediaTek mt76 mt7915 Wi-Fi driver. During PCI device removal, the driver frees mt7915 crash dump memory while a queued or running workqueue task, mt7915_mac_dump_work(), may still dereference that freed crash_data structure. The upstream fix synchronizes teardown by cancelling pending or executing dump work before deallocating crash_data. In practical terms, the flaw can cause kernel memory corruption and likely denial of service through a kernel crash; depending on allocator state, kernel configuration, and attacker control over the race, memory corruption bugs of this class can sometimes become privilege-escalation primitives, but no public exploitation is indicated by the provided data.

Why it matters to the business

Systems using affected Linux kernels with MediaTek MT7915/mt76 Wi-Fi hardware may experience instability, crashes, or service interruption during device reset, recovery, or removal events. The operational impact is most relevant to wireless routers, access points, embedded Linux devices, and servers or appliances using this chipset. Current exploitation likelihood appears low: EPSS is 0.00125, exploit maturity is listed as none, and it is not in CISA KEV or marked as ransomware-used. Even so, organizations relying on affected wireless infrastructure should treat kernel updates as part of normal reliability and hardening maintenance.

How an attack unfolds

An attacker would need conditions that cause the mt7915 driver to enter recovery/reset or device teardown while the driver's dump work item is queued or executing. The vulnerable sequence occurs when one execution path unregisters the device and frees dev->coredump.crash_data, while another path later runs mt7915_mac_dump_work() and dereferences the freed memory. If the race is won, the kernel may access invalid memory, producing a crash or other memory corruption. Remote exploitation is not straightforward from the advisory alone; a plausible trigger would involve causing repeated Wi-Fi device recovery/reset conditions, while local or physical access paths may involve hot-unplug, driver unload, suspend/resume, or PCI device removal workflows. There are no known named threat actors or public exploit reports in the supplied data.

How to fix it

Apply the vendor or distribution kernel update that includes the mt76 mt7915 fix adding cancel_work_sync() in mt7915_unregister_device() before crash_data is deallocated. Because no exact affected product list or fixed package versions were provided, use Linux distribution advisories and upstream stable kernel changelogs to identify patched kernel builds for deployed platforms. Where immediate patching is not possible, reduce exposure by disabling or unloading the mt7915/mt76 driver on systems that do not require it, avoiding hot-unplug or repeated reset workflows, and limiting untrusted users' ability to trigger driver reloads, PCI device removal, suspend/resume operations, or wireless recovery actions. For appliances and embedded devices, obtain firmware images from the vendor that incorporate the patched kernel.

How to confirm the fix worked

Confirm the running kernel package or appliance firmware includes the upstream mt76 mt7915 change that cancels dump_work before freeing crash_data. Validate by checking distribution security advisories, kernel package changelogs, or source patches for mt7915_unregister_device() calling cancel_work_sync() for the dump work path before mt7915_coredump_unregister() frees crash_data. Confirm whether the host is exposed by checking for loaded mt76/mt7915-related modules and MediaTek MT7915 PCI hardware. After patching, perform controlled driver restart, interface reset, suspend/resume, or device removal testing in a non-production environment and verify that no kernel warnings, KASAN use-after-free reports, oopses, or crashes occur.

Typical attack path

1. Identify a target running a vulnerable Linux kernel with the mt76 mt7915 Wi-Fi driver and compatible MediaTek MT7915 PCI hardware.
2. Trigger conditions that cause mt7915 reset, recovery, or device removal while crash dump work may be queued.
3. Race the driver teardown path so mt7915_coredump_unregister() frees crash_data before mt7915_mac_dump_work() completes or starts.
4. Cause mt7915_mac_dump_work() to dereference the freed crash_data pointer.
5. Achieve kernel instability or crash; in a more advanced scenario, attempt to shape kernel memory reuse to influence the use-after-free outcome.

How to detect it

Review kernel and system logs for signs that the mt7915 driver hit the vulnerable race condition before patching. Useful sources include dmesg output, journald kernel logs, /var/log/kern.log, /var/log/messages, crash dump directories, kdump/vmcore artifacts, and kernel sanitizer reports if KASAN or similar debugging is enabled. Look for mt7915 reset or recovery activity followed closely by workqueue faults, use-after-free reports, page faults, general protection faults, kernel oopses, or panics involving mt7915_mac_dump_work, mt7915_coredump_unregister, mt7915_unregister_device, or mt7915_pci_remove. Also review administrative audit logs for driver unload/reload, PCI unbind/remove operations, suspend/resume cycles, firmware crashes, or repeated wireless resets around the time of a crash. There are no reliable remote network IOCs for this vulnerability from the supplied data; detection is primarily host-based and crash-forensic.

• mt7915_mac_dump_work
• mt7915_coredump_unregister
• mt7915_unregister_device
• mt7915_pci_remove
• mt7915_sys_recovery_set
• mt7915_reset
• mt76
• mt7915
• use-after-free
• KASAN: use-after-free
• BUG: KASAN: use-after-free
• workqueue
• kernel BUG
• Oops
• general protection fault
• unable to handle kernel paging request
• kernel panic
• vfree
• crash_data
• /var/log/kern.log
• /var/log/messages
• /var/crash
• /proc/vmcore

What your security team should do

• Inventory Linux systems, access points, routers, and embedded appliances that use MediaTek MT7915 hardware or load mt76/mt7915-related kernel modules.
• Prioritize patching systems where Wi-Fi availability is operationally important or where untrusted users can influence wireless resets, driver loading, suspend/resume, or device removal behavior.
• Track Linux distribution and device-vendor advisories for the patched kernel or firmware build, because exact fixed versions were not provided in the input.
• If patching must be delayed, disable the affected Wi-Fi hardware or driver where feasible and restrict administrative capabilities that can trigger module unload, PCI removal, or device reset paths.
• Monitor kernel logs for mt7915 recovery/reset events, use-after-free warnings, workqueue crashes, and kernel oops/panic messages that may indicate attempted triggering or instability.
• Because this is not listed in KEV, not ransomware-associated, has low EPSS, and has no known exploit maturity, handle as a reliability and defense-in-depth kernel update rather than an emergency internet-wide exploitation event.