CVE-2026-80949

What it actually does

A kernel memory leak in the Broadcom FullMAC (brcmfmac) SDIO Wi-Fi driver leaves a vmalloc-allocated control buffer unfreed on some error paths in brcmf_sdio_read_control(). Repeated hits on those paths grow unreclaimed kernel virtual memory, which can exhaust vmalloc space, degrade I/O and wireless performance, and eventually invoke the OOM killer or hang the host. This is a local/availability defect, not a memory-corruption or privilege-escalation primitive.

Why it matters to the business

Linux laptops, embedded systems, and IoT devices that use Broadcom SDIO Wi-Fi can become slow, unstable, or unusable if the leaky error paths fire often, disrupting wireless connectivity and long-running unattended workloads. Exploit maturity is none, EPSS is very low (~0.177%) and unchanged over 30 days, the issue is not in CISA KEV, and there is no reported ransomware use, so organization-wide urgency is low except for memory-constrained or high-availability fleets still running unpatched vendor kernels.

How an attack unfolds

There are no known in-the-wild exploits or named threat actors. An adversary who can repeatedly force the brcmfmac SDIO control-read path to fail—by inducing malformed or incomplete control frames from the wireless/firmware side, stressing or disrupting the SDIO link, or otherwise causing the driver to take the unfixed error returns—causes the kernel to allocate buffers that are never vfree()'d. Over time kernel memory is exhausted and the host denies service. Exploitation requires a vulnerable brcmfmac SDIO stack and a way to trigger those error conditions at volume; it does not by itself yield code execution or credential theft.

How to fix it

Apply a Linux kernel update that includes the brcmfmac fix adding vfree() on all error paths in brcmf_sdio_read_control(). Use the distribution or vendor kernel that backports that change; no specific upstream version numbers were published with this advisory. If wireless is not required, unload or blacklist brcmfmac as a temporary mitigation. Reboot onto the patched kernel so the in-memory driver is replaced.

How to confirm the fix worked

Confirm the running kernel changelog or package notes include the brcmfmac brcmf_sdio_read_control() leak fix, and that brcmfmac.ko on disk matches that kernel. Verify with lsmod whether brcmfmac is loaded and whether the interface is SDIO-backed. After patching, exercise Wi-Fi association and error handling and confirm /proc/vmallocinfo and overall kernel memory do not grow without bound. On unpatched systems, treat unexplained vmalloc growth coincident with brcmfmac SDIO errors as evidence of exposure.

Typical attack path

1. Locate a Linux system whose wireless stack loads the brcmfmac SDIO driver (Broadcom FullMAC over SDIO).
2. Establish a position from which SDIO control-frame processing can be stressed (local access, wireless proximity, or a condition that makes the chip/firmware return errors).
3. Repeatedly cause brcmf_sdio_read_control() to take error paths so the allocated control buffer is not freed.
4. Wait for kernel vmalloc/OOM pressure to degrade or crash the host, denying wireless and potentially other services.

How to detect it

This leak leaves no classic malware artifacts. Hunt for availability symptoms on hosts that load brcmfmac: repeated brcmfmac/SDIO errors in kernel logs (dmesg, journalctl -k), steadily climbing vmalloc or unreclaimable kernel memory, and OOM-killer events whose stacks mention brcmfmac or brcmf_sdio. Correlate with wireless instability or SDIO faults. Absence of those signals does not prove the bug was never hit; it only means exhaustion may not have occurred yet. There is no network signature unique to this CVE.

• kernel: brcmfmac
• brcmf_sdio_read_control
• brcmf_sdio
• Out of memory:.*brcmf

What your security team should do

• Inventory Linux endpoints and embedded images for a loaded or shipped brcmfmac SDIO driver and prioritize those that must stay up for long periods.
• Deploy vendor/distribution kernels that contain the brcmf_sdio_read_control() vfree() fix; reboot to activate.
• Where Wi-Fi is unused, blacklist brcmfmac until the patched kernel is in place.
• Track this as a low-urgency availability issue (not KEV, negligible EPSS, no known exploits) unless devices are memory-constrained or safety-critical.
• After rollout, sample kernel logs and vmalloc usage on a subset of Broadcom Wi-Fi hosts to confirm the leak no longer accumulates.