CVE-2026-46069

What it actually does

This is a Linux kernel use-after-free in the mwifiex wireless driver cleanup path. The vulnerable code deletes the adapter wakeup timer with a non-synchronous timer deletion routine, allowing the timer callback to continue running while the adapter object is being freed. If the race is won, the callback can dereference freed kernel memory, which may lead to kernel memory corruption, local privilege escalation, information disclosure, or system crash. The issue requires local access and an affected system using the mwifiex Wi-Fi driver or related Marvell wireless hardware support.

Why it matters to the business

Systems that use the affected Linux kernel mwifiex Wi-Fi driver may allow a local user or process to crash the host or potentially gain kernel-level privileges. The main operational risks are endpoint or appliance instability, denial of service, and escalation from a low-privileged local account to full system control. This is not currently listed in CISA KEV, has no known public exploit maturity, and has a low EPSS score, so broad internet-scale exploitation is unlikely; however, kernel local privilege-escalation flaws remain important on multi-user Linux systems, developer workstations, kiosks, embedded devices, and appliances with Wi-Fi hardware.

How an attack unfolds

An attacker first needs local code execution or an authenticated local account on a Linux system using the vulnerable mwifiex driver. The attacker then attempts to trigger the mwifiex adapter cleanup path while the wakeup timer callback is running, such as by forcing device removal, driver unload, reset, suspend/resume behavior, or other state transitions that cause adapter teardown. Because the vulnerable cleanup routine does not wait for an in-flight timer callback to finish, the adapter structure can be freed while the callback still references fields inside it. A simple exploit may only cause a kernel oops or panic, producing denial of service. A more reliable exploit would attempt to shape kernel heap allocations so the freed adapter memory is reallocated with attacker-influenced data, turning the stale callback dereference into controlled memory corruption and possible elevation to kernel privileges.

How to fix it

Upgrade to a Linux kernel build from the relevant distribution or vendor that includes the mwifiex fix changing wakeup_timer cleanup to a synchronous timer deletion, timer_delete_sync(). No exact package fixed versions were provided in the input, so remediation should be based on the kernel advisory stream for the affected distribution, device vendor, or long-term stable kernel branch. After installing the fixed kernel, reboot into the updated kernel to remove the vulnerable code from memory. If immediate patching is not possible and the hardware/feature is not required, mitigate by disabling the affected mwifiex driver stack, including applicable mwifiex modules such as mwifiex, mwifiex_pcie, mwifiex_sdio, or mwifiex_usb, or by disabling the affected Wi-Fi device in firmware, kernel module policy, or device configuration. Restrict local shell access and untrusted local workloads on affected systems until patched.

How to confirm the fix worked

Confirm the running kernel is the vendor-fixed build, not merely that an updated package is installed. On Linux systems, compare `uname -r` with the distribution security advisory and verify that the system has been rebooted after the update. Where source or debug symbols are available, confirm the mwifiex cleanup path uses synchronous timer deletion for the adapter wakeup timer, specifically timer_delete_sync() or the vendor-equivalent fix. Check whether affected modules are loaded with commands such as `lsmod | grep mwifiex` and `modinfo mwifiex`; if the driver is not needed, validate that module blacklisting or device disablement persists across reboot. Review kernel logs after remediation for absence of recurring mwifiex-related kernel oops, KASAN use-after-free reports, or crashes during Wi-Fi reset, suspend/resume, or module unload testing.

Typical attack path

1. Gain local execution on a Linux system with the affected mwifiex wireless driver loaded.
2. Confirm the mwifiex adapter is present and that the vulnerable kernel build is in use.
3. Repeatedly trigger mwifiex adapter teardown conditions such as driver unload, device reset, suspend/resume, or simulated removal while the wakeup timer is active.
4. Race the wakeup_timer_fn callback against mwifiex_adapter_cleanup() and mwifiex_free_adapter().
5. Cause the timer callback to access the freed adapter object.
6. Use the resulting use-after-free to crash the kernel or attempt controlled kernel memory corruption for privilege escalation.

How to detect it

Because exploitation is local and race-condition based, there may be no network indicator and successful exploitation may leave only kernel crash or memory-corruption evidence. Review kernel logs, system journal entries, crash dumps, pstore records, and KASAN/KFENCE reports for mwifiex-related use-after-free traces, especially around Wi-Fi reset, suspend/resume, device removal, or driver unload events. Relevant log sources include `/var/log/kern.log`, `/var/log/messages`, `journalctl -k`, `dmesg`, `/sys/fs/pstore/`, and kernel crash dump facilities such as kdump/vmcore. Look for stack traces referencing wakeup_timer_fn, mwifiex_adapter_cleanup, mwifiex_free_adapter, mwifiex_remove_card, or timer deletion during adapter teardown. Also review audit logs and shell/process history for suspicious local attempts to repeatedly unload/reload mwifiex modules, manipulate PCI/SDIO/USB Wi-Fi devices, trigger suspend/resume cycles, or run local kernel exploit tooling. Absence of these artifacts does not prove absence of exploitation, especially if logs were rotated or the system crashed without persistent crash logging.

• KASAN: use-after-free
• BUG: KASAN: use-after-free
• use-after-free in wakeup_timer_fn
• wakeup_timer_fn
• mwifiex_adapter_cleanup
• mwifiex_free_adapter
• mwifiex_remove_card
• Modules linked in: mwifiex
• mwifiex_pcie
• mwifiex_sdio
• mwifiex_usb
• /sys/fs/pstore/
• journalctl -k
• kernel: BUG: unable to handle page fault
• kernel: general protection fault
• kernel panic
• rmmod mwifiex
• modprobe -r mwifiex

What your security team should do

• Prioritize patching Linux endpoints, embedded systems, and appliances that have Marvell/mwifiex wireless hardware or load the mwifiex driver.
• Reboot systems after kernel updates to ensure the fixed kernel is active.
• Inventory systems with mwifiex-related modules loaded or available, especially multi-user Linux hosts and devices where local users or applications are not fully trusted.
• If patching is delayed, disable or blacklist unused mwifiex driver modules and disable affected Wi-Fi hardware where operationally acceptable.
• Treat unexplained kernel crashes involving mwifiex, wakeup_timer_fn, or KASAN use-after-free reports as potential exploitation attempts and preserve logs for investigation.
• Monitor distribution and kernel stable-branch advisories for exact fixed package versions applicable to each Linux platform in use.