CVE-2026-53093

What it actually does

This flaw is an error-pointer dereference in the Linux kernel Broadcom FullMAC Wi-Fi driver, brcmfmac. During Broadcom Wi-Fi chip recognition, brcmf_chip_add_core() may return an ERR_PTR value, but the caller can dereference it as though it were a valid core structure. If the vulnerable code path is reached during Wi-Fi device probing or initialization, the kernel can trigger an oops, panic, or driver failure, resulting in denial of service for the affected system or loss of wireless networking.

Why it matters to the business

Systems that rely on affected Broadcom Wi-Fi hardware may become unstable, lose wireless connectivity, or crash when the vulnerable driver path is triggered. The operational impact is most relevant to laptops, embedded Linux systems, appliances, IoT devices, and other devices using the brcmfmac driver. Current public exploitation indicators are low: this issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, has no reported exploit maturity, and has a very low EPSS score, but kernel driver crashes can still be disruptive where device availability is important.

How an attack unfolds

An attacker would need a way to influence Broadcom Wi-Fi device initialization or chip/core enumeration so that brcmf_chip_add_core() returns an error pointer. Because the vulnerable caller does not validate that return value, subsequent accesses to the returned core object can dereference the encoded error pointer. In practical terms, exploitation is most plausible through local, physical, or adjacent-device conditions involving vulnerable Broadcom Wi-Fi hardware, malformed or unexpected device responses, faulty hardware states, or crafted test conditions during driver probing. Successful exploitation is expected to cause denial of service rather than code execution: the brcmfmac driver or kernel may crash, panic, or leave Wi-Fi nonfunctional.

How to fix it

Upgrade to a Linux kernel or vendor kernel package that includes the brcmfmac fix adding ERR_PTR validation after brcmf_chip_add_core(). If exact fixed versions are not provided by the upstream advisory for a given distribution, use the latest security-supported kernel from the operating system or device vendor and confirm the backported patch is present. Where immediate patching is not possible, reduce exposure by disabling unused Broadcom Wi-Fi interfaces, unloading or blacklisting the brcmfmac module on systems that do not require it, using wired networking where operationally acceptable, and restricting physical or administrative access that could trigger repeated device reprobe or module reload events.

How to confirm the fix worked

Confirm whether systems load the vulnerable driver by checking for the brcmfmac module with tools such as lsmod, modinfo, dmesg, or distribution inventory tooling. Validate remediation by confirming the installed kernel package includes the upstream fix for unchecked ERR_PTR handling in drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c, especially in brcmf_chip_recognition(). Reboot into the patched kernel and verify that brcmfmac initializes normally without kernel oops messages. For mitigations, confirm that the module is not loaded, that blacklist configuration is effective after reboot, or that Broadcom Wi-Fi hardware is disabled where intended.

Typical attack path

1. Identify a Linux system using Broadcom FullMAC Wi-Fi hardware and the brcmfmac kernel driver.
2. Trigger Wi-Fi device probing, reinitialization, suspend/resume recovery, module loading, or another code path that invokes Broadcom chip recognition.
3. Cause brcmf_chip_add_core() to fail and return an ERR_PTR value during chip/core discovery.
4. Allow brcmf_chip_recognition() to dereference the unchecked error pointer.
5. Induce a kernel oops, panic, driver fault, or loss of wireless network functionality.

How to detect it

To assess possible prior exploitation or triggering, review kernel logs, persistent journal entries, crash dumps, and endpoint telemetry for brcmfmac initialization failures followed by kernel oops, panic, reboot, or wireless device disappearance. Useful sources include dmesg output, /var/log/kern.log, /var/log/messages, /var/log/syslog, systemd-journald kernel logs, kdump/vmcore data, crash reporting tools, and EDR telemetry for kernel panic or unexpected reboot events. Look for events around Wi-Fi module load/unload, device probe, suspend/resume, hotplug, or firmware initialization. Distinguish exploitation attempts from benign hardware faults by looking for repeated brcmfmac crashes, recurrence after module reloads, or correlation with physical access, device insertion, suspend/resume cycles, or administrative commands such as modprobe/rmmod. There are no public reports of active exploitation or named threat actors for this issue, so detection should focus on crash artifacts and anomalous brcmfmac driver behavior rather than known attacker infrastructure.

• brcmfmac
• brcmf_chip_recognition
• brcmf_chip_add_core
• drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
• kernel BUG
• Oops
• Kernel panic
• Unable to handle kernel
• general protection fault
• NULL pointer dereference
• ERR_PTR
• brcmfmac: brcmf_chip_recognition
• brcmfmac: brcmf_chip_add_core
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• /sys/module/brcmfmac
• brcmfmac.ko

What your security team should do

• Inventory Linux endpoints, embedded systems, and appliances that use Broadcom FullMAC Wi-Fi hardware or load the brcmfmac driver.
• Prioritize kernel updates for systems where Wi-Fi availability is business-critical, where devices are physically accessible to untrusted users, or where repeated crashes could affect operations.
• Track vendor kernel advisories because distribution kernels may receive this fix through backports rather than a simple upstream version match.
• If patching is delayed, disable or blacklist brcmfmac on systems that do not require Broadcom Wi-Fi functionality.
• Monitor kernel logs for brcmfmac-related oops, panic, probe failure, or repeated module reload events that could indicate attempted triggering or unstable hardware.
• Because EPSS is very low, the issue is not in KEV, and no mature exploit is reported, treat this as a kernel stability and availability patch rather than an internet-facing emergency unless affected devices are operationally critical.