CVE-2026-46180

What it actually does

This vulnerability is a use-after-free race condition in the Linux kernel Broadcom FullMAC Wi-Fi driver, brcmfmac. During watchdog task shutdown, the watchdog kernel thread can exit between signal delivery and the subsequent stop operation, leaving kernel code operating on a freed task structure. A local user with sufficient ability to trigger relevant Wi-Fi driver teardown or reset paths could potentially cause kernel memory corruption. The practical outcomes may include a kernel crash, denial of service, or, in a successful exploitation scenario, local privilege escalation with kernel-level code execution. The CVSS vector indicates local access, low attack complexity, required low privileges, no user interaction, and high confidentiality, integrity, and availability impact.

Why it matters to the business

Systems using affected Linux kernels with Broadcom FullMAC Wi-Fi hardware may be exposed to local privilege escalation or system instability. The most likely operational impact is device crash or unplanned reboot, but successful exploitation could allow an attacker who already has local access to gain full control of the operating system. This is especially relevant for laptops, embedded Linux devices, IoT systems, kiosks, and appliances that rely on Broadcom Wi-Fi chipsets. The vulnerability is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has low EPSS, so broad internet-scale exploitation is unlikely; however, kernel privilege-escalation flaws should still be prioritized on systems where untrusted local users, containers, or exposed application workloads could reach the affected driver paths.

How an attack unfolds

An attacker first obtains local code execution with low privileges on a system running an affected Linux kernel and using the brcmfmac Broadcom Wi-Fi driver. The attacker then attempts to manipulate Wi-Fi device state, driver unload or shutdown behavior, suspend/resume, interface resets, or other paths that stop the brcmfmac watchdog task. By repeatedly triggering the race window where the watchdog task exits between signal delivery and the kernel stop operation, the attacker may cause the kernel to reference a freed task object. In simple cases, this results in a kernel oops, panic, or reboot. With reliable heap shaping and kernel exploitation techniques, the attacker may attempt to turn the use-after-free into arbitrary kernel memory access and elevate privileges to root or kernel-level execution. There is no public exploit maturity indicated in the provided data, so exploitation should be considered plausible but not currently known to be commoditized.

How to fix it

Upgrade to a Linux kernel version or distribution kernel package that includes the brcmfmac watchdog task lifetime fix. The upstream fix increases the watchdog task reference count before signaling it and releases it safely by using kthread_stop_put(), preventing use-after-free during shutdown. Because no exact fixed versions were provided, use vendor advisories for the relevant distribution or appliance platform to identify the first fixed kernel package. Where immediate patching is not possible, reduce exposure by disabling unused Broadcom Wi-Fi functionality, blacklisting the brcmfmac module if Wi-Fi is not required, restricting local shell access, limiting untrusted workloads on affected hosts, and ensuring kernel lockdown, module signing, SELinux/AppArmor, and least-privilege controls are enabled. Mitigations do not replace patching because the flaw is in kernel driver logic.

How to confirm the fix worked

Confirm that systems are running a kernel build that contains the brcmfmac watchdog task fix from the relevant Linux distribution, OEM, or appliance vendor. Validate package versions with the platform package manager and compare them against vendor security advisories. Check whether the affected driver is present or loaded using commands such as lsmod, modinfo brcmfmac, and dmesg searches for brcmfmac. For source-based or custom kernels, confirm the patched logic around watchdog task stopping includes safe task reference handling and kthread_stop_put(). After remediation, reboot into the fixed kernel and verify that the running kernel version, not just the installed package version, is updated. If Wi-Fi is not needed and the driver is disabled as a mitigation, verify that brcmfmac is not loaded after reboot and cannot be auto-loaded by normal device activity.

Typical attack path

1. Gain local low-privileged execution on a Linux system using an affected kernel and Broadcom FullMAC Wi-Fi hardware.
2. Confirm the brcmfmac driver is loaded or trigger conditions that cause the driver to initialize.
3. Repeatedly manipulate Wi-Fi state, driver reset, suspend/resume, interface teardown, or module/device shutdown paths that stop the brcmfmac watchdog task.
4. Race the watchdog task exit against the kernel stop operation to trigger use-after-free behavior.
5. Cause kernel memory corruption, typically resulting in a crash, panic, or reboot.
6. If exploit reliability is achieved, use the memory corruption primitive to escalate privileges or execute code in kernel context.

How to detect it

There is no single definitive log entry that proves exploitation because this is a kernel race condition and failed attempts may look like ordinary driver instability. Investigate systems that show unexpected reboots, kernel panics, or oops reports involving brcmfmac, watchdog task shutdown, kthread_stop, send_sig, task reference handling, or KASAN use-after-free findings. Relevant log sources include journalctl kernel logs, /var/log/kern.log, /var/log/messages, dmesg output, persistent pstore/ramoops logs, crash dumps, kdump vmcores, endpoint telemetry for local command execution, and audit logs showing users repeatedly manipulating Wi-Fi interfaces, unloading or reloading modules, suspending or resuming devices, or triggering network interface resets. Look for repeated sequences of brcmfmac driver initialization and teardown followed by kernel faults or reboots. On systems with kernel sanitizers or debugging enabled, prioritize any KASAN, KFENCE, slab, refcount, or general protection fault reports that mention brcmfmac watchdog handling. Because exploitation requires local access, correlate crash artifacts with recent local logins, container escapes attempts, suspicious scripts, or unusual use of tools such as ip, iw, rfkill, modprobe, rmmod, or system power-management commands.

• brcmfmac
• KASAN: use-after-free
• BUG: KASAN
• use-after-free
• watchdog task
• kthread_stop
• kthread_stop_put
• send_sig
• kernel BUG
• Oops:
• general protection fault
• Kernel panic
• brcmfmac:
• rmmod brcmfmac
• modprobe brcmfmac
• iw dev
• rfkill
• pstore
• ramoops

What your security team should do

• Inventory Linux systems that use Broadcom FullMAC Wi-Fi hardware or load the brcmfmac kernel module.
• Prioritize patching endpoints, embedded devices, kiosks, and appliances where local users or untrusted workloads can execute code.
• Apply the vendor-provided kernel update containing the brcmfmac watchdog task lifetime fix, then reboot into the fixed kernel.
• If patching is delayed and Wi-Fi is not required, disable or blacklist the brcmfmac module as a temporary mitigation.
• Restrict local interactive access and reduce privileges for users and services on affected systems until patched.
• Monitor kernel logs for brcmfmac-related crashes, watchdog task errors, KASAN reports, use-after-free messages, oopses, panics, or unexplained reboots.
• For high-risk systems, preserve crash dumps and kernel logs before rebooting or reimaging to support forensic review.
• Track distribution and OEM advisories because exact fixed package versions vary by kernel branch and vendor backporting policy.