CVE-2026-53097

What it actually does

This is a Linux kernel use-after-free race in the MediaTek mt76 mt7996 Wi-Fi driver. During PCI device removal or driver detach, the driver frees mt7996 crash dump state in the coredump unregister path while an asynchronous dump_work workqueue item may still be queued or executing. If mt7996_mac_dump_work() later dereferences the freed crash_data pointer, the kernel can access invalid memory. The most likely impact is a kernel crash or system instability; depending on allocator state and attacker control over timing and reclaimed memory, kernel memory corruption could theoretically lead to privilege escalation or arbitrary kernel execution, but no public exploit maturity is reported.

Why it matters to the business

Systems using affected Linux kernels with MediaTek mt7996-based Wi-Fi hardware may experience crashes, reboots, or network disruption during device reset, recovery, driver unload, hotplug, or removal scenarios. Because this is in kernel-space code, failures can affect the whole host rather than only Wi-Fi functionality. Current exploitation likelihood appears low, with low EPSS, no known CISA KEV listing, and no reported ransomware use, but the operational risk is higher for appliances, access points, embedded systems, or servers that rely on this chipset and perform unattended updates, driver reloads, or hardware recovery.

How an attack unfolds

An attacker must first be in a position to influence the affected mt7996 Wi-Fi driver state, typically by triggering or racing device recovery/reset behavior with driver or PCI device removal. One path is a local attacker with sufficient ability to unbind the driver, remove the PCI device, reload kernel modules, or otherwise cause teardown while recovery work is pending. A less direct path could involve provoking Wi-Fi firmware recovery conditions and relying on another management action to detach the device at the same time. The vulnerable sequence occurs when the removal path frees the crash_data buffer before ensuring the dump_work work item has stopped. If the workqueue runs afterward, mt7996_mac_dump_work() dereferences freed memory, causing a kernel use-after-free. Practical exploitation is timing-dependent and hardware-specific; expected outcomes are denial of service through kernel panic or instability, with more severe exploitation requiring reliable memory grooming in kernel space.

How to fix it

Apply a Linux kernel update that includes the mt76 mt7996 fix adding synchronization of dump_work before freeing crash dump data, specifically cancel_work_sync() in the mt7996 device unregister path. Because no exact fixed package versions were provided, use the fixed kernel supplied by the relevant Linux distribution, device vendor, appliance vendor, or upstream stable kernel branch once available. For systems that cannot be updated immediately, reduce exposure by disabling or removing affected mt7996 hardware where feasible, avoiding unnecessary driver unload/reload or PCI hotplug operations, and limiting local administrative interfaces that can trigger driver unbind, module reload, or device reset. On embedded or network appliance platforms, obtain vendor firmware images that include the corrected kernel driver rather than attempting partial driver replacement unless vendor-supported.

How to confirm the fix worked

Confirm that running kernels include the upstream mt76 mt7996 change that cancels dump_work before coredump crash_data is freed. Validate by checking the installed kernel package changelog, distribution security advisory, vendor firmware release notes, or source tree for the relevant mt7996_unregister_device() change using cancel_work_sync() for the coredump dump work. Confirm whether the system loads the affected driver by checking for mt7996/mt76 modules and compatible PCI devices. After patching, reboot into the fixed kernel and verify the active kernel version, loaded module build, and absence of mt7996-related KASAN, use-after-free, workqueue, or kernel panic messages during driver reload, device recovery, suspend/resume, shutdown, or controlled Wi-Fi reset testing.

Typical attack path

1. Identify a Linux system using the mt76 mt7996 Wi-Fi driver and MediaTek mt7996-compatible hardware.
2. Induce or wait for mt7996 recovery, reset, or crash dump activity that queues dump_work.
3. Concurrently trigger device detach, PCI removal, driver unbind, module unload, reboot/shutdown teardown, or another path that calls mt7996_unregister_device().
4. Race the teardown path so mt7996_coredump_unregister() frees crash_data while dump_work remains pending or running.
5. Allow mt7996_mac_dump_work() to execute and dereference the freed crash_data pointer.
6. Cause kernel instability, panic, or potentially attempt further kernel memory corruption if the freed allocation can be reclaimed in a controlled way.

How to detect it

Look for evidence of crashes or memory-safety failures in kernel logs and crash dumps on systems using the mt76 mt7996 driver. Useful sources include journald, dmesg, /var/log/kern.log, /var/log/messages, pstore/ramoops, kdump/vmcore analysis, hypervisor console logs, appliance diagnostic bundles, and distribution crash reporting. Search for mt7996 or mt76 messages close in time to driver unload, PCI removal, firmware recovery, Wi-Fi reset, suspend/resume, shutdown, or reboot. Indicators of attempted or accidental triggering include kernel warnings or panics referencing mt7996_mac_dump_work(), mt7996_coredump_unregister(), mt7996_unregister_device(), mt7996_reset(), queue_work, cancel_work_sync absence in source validation, KASAN use-after-free reports, slab poisoning errors, general protection faults, or workqueue crashes. Because this flaw is a race condition in kernel cleanup logic, there may be no network-layer IOC; investigation should focus on local kernel telemetry, administrative actions that caused driver detach, and repeated unexplained crashes correlated with mt7996 Wi-Fi recovery or device removal.

• mt7996_mac_dump_work
• mt7996_coredump_unregister
• mt7996_unregister_device
• mt7996_sys_recovery_set
• mt7996_reset
• mt7996_pci_remove
• mt76
• mt7996
• KASAN: use-after-free
• BUG: KASAN: use-after-free
• kernel BUG at
• general protection fault
• workqueue
• dump_work
• crash_data
• vfree
• queue_work
• mt7996:
• mt76:

What your security team should do

• Inventory Linux systems, embedded devices, access points, and appliances that use MediaTek mt7996 Wi-Fi hardware or load mt76/mt7996 kernel drivers.
• Prioritize patching internet-facing, remotely managed, high-availability, or unattended devices where kernel crashes would cause business disruption.
• Track distribution and vendor advisories for fixed kernel or firmware versions, since exact fixed versions were not provided in the input.
• Apply the fixed kernel or vendor firmware and reboot systems to ensure the corrected driver is running.
• Until patched, restrict access to operations that can unload modules, unbind PCI devices, reset Wi-Fi hardware, or trigger driver recovery paths.
• Monitor kernel logs for mt7996, mt76, workqueue, KASAN, slab, general protection fault, BUG, or panic messages that occur around Wi-Fi reset, firmware recovery, driver unload, or device removal.
• Treat unexpected kernel crashes on mt7996-equipped systems as potentially security-relevant and preserve logs, crash dumps, and kernel versions for investigation.