Broadcom Wi-Fi over-the-air code execution and denial of service

1. Summary

Four vulnerabilities in Broadcom Wi-Fi chipset drivers and firmware — three heap buffer overflows and one input-validation bypass — affect the HoloLens and were addressed by Microsoft via advisory ADV190017. Two overflows live in Broadcom’s proprietary wl driver and are triggered while parsing the WPA2 4-way handshake; one lives in the open-source Linux brcmfmac driver’s Wake-on-WLAN handler; and the fourth is a firmware-event-frame validation bypass in brcmfmac that lets remotely-injected event frames reach code that assumed they were locally originated. An unauthenticated attacker within Wi-Fi radio range of a HoloLens can crash the wireless driver (denial of service) or, in the harder case, achieve code execution in the wireless-driver/firmware context via the Broadcom chipset.

2. Affected products & versions

3. The vulnerability in detail

The heart of CPATH-2026-0014 is not one bug but a small family of related defects in Broadcom’s Wi-Fi stack, three of which share a single root-cause pattern and one of which quietly turns a “local-only” bug into a remotely-reachable one. Understanding them together is what makes the HoloLens exposure legible.

Three of the four issues are classic heap buffer overflows — out-of-bounds writes (CWE-787) of the heap-based-buffer-overflow flavor (CWE-122). The common defect is the same each time: the code trusts an attacker-controlled length field and copies that many bytes into a fixed-size destination buffer without first checking that the length fits [1][2][3]. In wlc_wpa_sup_eapol (CVE-2019-9501), the driver copies a vendor information element whose data length can exceed 32 bytes, overrunning the destination [2]. In wlc_wpa_plumb_gtk (CVE-2019-9502), the same shape recurs against a buffer sized for 164 bytes of GTK/IE data — supply more and the copy runs off the end [3]. In brcmf_wowl_nd_results (CVE-2019-9500), the handler copies an SSID using an untrusted length taken from event data, even though 802.11 caps SSIDs at 32 bytes; the missing clamp against that protocol constant is the bug [1][7].

These two wl-driver overflows are reached through the WPA2 4-way handshake [7]. An attacker stands up a rogue access point (or injects frames) and, during association, delivers an EAPOL-Key Message 3 (M3) carrying an oversized vendor information element or GTK. When the victim’s driver parses M3, it performs the unchecked copy and corrupts the heap. Which heap depends on the chip architecture: on SoftMAC parts the parsing runs in the host kernel, so the corruption lands in kernel heap; on FullMAC parts it runs on-chip, so the corruption lands in firmware heap [7]. The immediate mechanical outcome of the corruption is a driver/firmware crash; converting the same corruption into code execution requires remote heap-layout grooming (heap spray / manipulation), which Quarkslab assessed as technically feasible but hard [7].

The brcmf_wowl_nd_results overflow (CVE-2019-9500) is mechanically distinct because on its own it is not reachable from off-device: it fires when Wake-on-Wireless-LAN is enabled and the device processes a firmware event frame carrying an over-length SSID [1]. Normally brcmfmac protects itself here — is_wlc_event_frame is supposed to reject firmware event frames that arrived from off-device, since legitimate event frames come from the chip’s own firmware, not the air. This is where the fourth bug matters. CVE-2019-9503 is an improper-input-validation defect (CWE-20): is_wlc_event_frame only treats a frame as an event frame worth discarding when the subtype low byte is negative [7]. Supply a frame with a non-negative subtype — plus ethertype 0x886c and a valid BRCM OUI — and the validator waves it through, so the driver processes an attacker-crafted “firmware” event as if it were trustworthy [4][7]. NVD/[4] scopes this bypass specifically to the USB bus (for example a Wi-Fi dongle); Quarkslab’s writeup [7] and the CERT/CC coordination [5] describe the affected brcmfmac surface more broadly as USB/PCIe FullMAC parts, so the mechanically-affected surface may extend to PCIe, but the primary advisory wording is USB. In all readings the SDIO bus is not affected, because SDIO uses a separate event channel that this injection cannot reach [7].

Chaining the two brcmfmac bugs produces the full remote path: CVE-2019-9503 gets an attacker-crafted event frame accepted, and (with Wake-on-WLAN enabled) that frame carries the over-length SSID that overflows the kernel heap in brcmf_wowl_nd_results (CVE-2019-9500) [1][7]. What would have been a local trust assumption becomes an over-the-air kernel heap overflow.

Step-by-step, the exploitation chain reads: (1) the attacker positions within Wi-Fi RF range of the HoloLens — adjacent-network vector, no authentication, no prior association [5]. (2a) Path A (wl driver): the attacker lures a WPA2 4-way handshake from a rogue AP and sends EAPOL-Key M3 with an oversized IE (>32 bytes → CVE-2019-9501) or oversized GTK (>164 bytes → CVE-2019-9502), corrupting kernel or firmware heap. (2b) Path B (brcmfmac): the attacker crafts an event frame (ethertype 0x886c, valid BRCM OUI, non-negative subtype) to slip past is_wlc_event_frame over the USB bus (CVE-2019-9503), then, with Wake-on-WLAN enabled, delivers the over-length-SSID event that overflows brcmf_wowl_nd_results (CVE-2019-9500). (3) The mechanical outcome is a reliable driver crash / device reboot in the easy case, or attacker-controlled code execution in the wireless-driver/firmware (kernel-adjacent) authority in the hard case [5][7].

Two mechanical details govern which devices are chain-exposed and by which path. First, the bus scoping above is a property of the injection surface: the remote event-injection concern is a USB-bus property in the authoritative NVD record [4] (broadened to USB/PCIe in the researcher writeup [7]), and SDIO is exempt — so whether a given device is chain-exposed depends on how its Broadcom part is attached. Second, the wl-driver overflows (Path A) do not depend on CVE-2019-9503 at all; they are reachable directly by luring the victim’s 4-way handshake, and are the branch NVD scores as the higher-severity RCE-capable pair (8.8) [2][3].

Proof-of-concept status: Quarkslab demonstrated PoC for the GTK/EAPOL overflows using a modified hostapd, confirming feasibility via kernel-panic traces on vulnerable SoftMAC devices [7]. The researcher’s overall assessment is that remote DoS is the most likely practical outcome, while RCE is feasible but hard [7].

4. Discovery & timeline

The research was performed by Hugues Anguelkov during an internship at Quarkslab (work conducted in 2018) and published in the Quarkslab blog post “Reverse-engineering Broadcom wireless chipsets” [7]. Disclosure was coordinated through CERT/CC as VU#166939, which ties all four CVEs together and names the exact vulnerable functions [5].

Per Quarkslab / CERT/CC: initial disclosure to Broadcom around September 2018; Broadcom declined coordination without an NDA; CERT/CC engaged around October 2018; Apple independently confirmed and coordinated a fix. CERT/CC records notification dates of January 11, 2019 (Broadcom/Apple) and April 9, 2019 (others), a public date of April 15, 2019, and first publication April 17, 2019 [5][7]. Microsoft shipped the HoloLens fix in the June 2019 HoloLens security update (ADV190017) [6].

5. Technical reference

• CVEs: CVE-2019-9500, CVE-2019-9501, CVE-2019-9502, CVE-2019-9503.
• CWEs: CVE-2019-9500/-9501/-9502 → CWE-787 (Out-of-bounds Write) and CWE-122 (Heap-based Buffer Overflow); CVE-2019-9503 → CWE-20 (Improper Input Validation).
• CVSS v3 vectors:
• CVE-2019-9501: 8.8 HIGH — AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H [2].
• CVE-2019-9502: 8.8 HIGH — AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H [3].
• CVE-2019-9500: 8.3 HIGH — AV:A/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H [1].
• CVE-2019-9503: 8.3 HIGH — AV:A/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H (identical to CVE-2019-9500; NVD also carries a CERT/CC-provided alternative 7.9 vector that includes user interaction [5]) [4].
• What the key metrics mean here: AV:A (Adjacent Network) is the crux — the attacker must be in Wi-Fi RF range, not on the Internet, which bounds reachability to physical proximity. PR:N/UI:N mean no credentials and no user action are required. For the wl overflows AC:L reflects the straightforward malicious-AP trigger; for CVE-2019-9500 and CVE-2019-9503 AC:H reflects the extra preconditions (Wake-on-WLAN enabled, the validation bypass, USB-bus attachment, and heap grooming for RCE), and S:C (Scope Changed) reflects that corruption in the wireless component crosses into broader system authority.
• Code/commit refs: brcmfmac CVE-2019-9503 fixed at/after upstream commit a4176ec356c73a46c07c181c6d04039fafa34a9f; Broadcom also provided silent patches to brcmfmac [4][7]. Vulnerable functions: brcmf_wowl_nd_results, is_wlc_event_frame (brcmfmac); wlc_wpa_sup_eapol, wlc_wpa_plumb_gtk (wl). Protocol context: 802.11 / WPA2 EAPOL-Key 4-way handshake; firmware event frames (ethertype 0x886c, BRCM OUI) [5][7].

6. Consequence & CFSE path analysis

Real-world consequence: on a head-worn mixed-reality display, an unauthenticated attacker standing within Wi-Fi range can, in the easy case, reliably crash the Wi-Fi driver and interrupt the wearer’s live workflow (forcing a reboot), and in the hard case gain code execution in the wireless-driver/firmware context — authority that sits adjacent to the kernel. On a HoloLens that context is co-resident with the device’s perception stack (cameras and live spatial-mapping / “world-model” state); reasoned inference — no cited source documents the internal reachability from the Wi-Fi/firmware context to those components on HoloLens specifically (not documented in any cited source). It is that plausible reach into perception and rendered-environment integrity on a device worn on someone’s face that would elevate this above a commodity Wi-Fi driver crash.

Why the CFSE Path Score differs from CVSS: CVSS scores each CVE as a self-contained flaw (base 8.3–8.8, HIGH) and does not model what the compromised component controls on this specific device. CFSE decomposes the HoloLens impact into two consequence paths and scores the consequence, not just the mechanism:

• DEVICE_CONTROL_SAFETY — CRITICAL (dominant path). Over-the-air, unauthenticated Wi-Fi proximity access (RE2) leads to a fragile, timing-sensitive heap-overflow RCE (EC1) that gains wireless-driver/kernel authority (AT3), crosses radio→device→perception/safety boundaries (CH4), and — on the reasoned inference that the compromised wireless component is co-resident with perception on a head-worn MR display — could reach camera and live spatial-mapping world-model state (DP4, PH3), reducing the wearer’s safety margin and rendered-environment integrity. This device-reachability step is inferred, not source-documented, so the promotion below is load-bearing on that inference and should be weighed accordingly.
• DEVICE_AVAILABILITY — HIGH (supporting path). Crafted Wi-Fi frames trivially and reliably crash the driver (EC4) to interrupt the wearer’s live workflow, but with no data exposure (DP0), bounded authority (AT2), and a device-reboot/patch recovery.

Both paths note a shared fleet-wide Broadcom-component primitive (SR4) but proximity-bound per-device execution (SX2); a patch is available. Overall path_verdict: CRITICAL, driven by the safety path, versus the published NVD/CERT CVSS baseline of HIGH (8.3–8.8). The divergence is deliberate: CFSE promotes the verdict because the safety-relevant reach of the compromised wireless component on a wearable perception device is a consequence CVSS’s device-agnostic base metrics do not capture — while flagging explicitly that this specific perception-reach step rests on reasoned inference rather than a cited source, and that a reader who declines that inference should read the safety path down toward the HIGH availability baseline.

7. Remediation & mitigations

• HoloLens (primary): install the June 2019 HoloLens security update, which delivers updated Broadcom firmware addressing the flaws named in ADV190017 [6]. This is the authoritative fix for the HoloLens fleet.
• Linux / brcmfmac: update to a brcmfmac build that includes the is_wlc_event_frame fix (upstream commit a4176ec356c73a46c07c181c6d04039fafa34a9f and related patches); apply Broadcom’s brcmfmac patches for the overflow paths [4][7].
• Other Broadcom-based devices: apply the relevant vendor firmware/driver updates (CERT/CC-coordinated vendors include Apple, Broadcom, Synology) [5].
• Mechanism-grounded workarounds (where patching lags):
• Avoid associating with untrusted / rogue Wi-Fi networks, since the wl-driver overflows (CVE-2019-9501/-9502) require the victim to engage a malicious AP’s 4-way handshake [7]. This is the only mitigation that touches Path A, which does not depend on the CVE-2019-9503 bypass.
• Where feasible disable Wake-on-Wireless-LAN, which is a precondition for the CVE-2019-9500 WOWL overflow path [7].
• Note the bus scoping: the CVE-2019-9503 event-injection bypass is scoped to the USB bus in the authoritative NVD record [4] (broadened to USB/PCIe FullMAC parts by the researcher writeup [7]); SDIO-bus devices are not affected because their separate event channel is not reachable this way [7]. The remote-chain concern is therefore specific to USB (and possibly PCIe) parts, not SDIO.

8. Sources

[1] NVD — CVE-2019-9500 (brcmfmac brcmf_wowl_nd_results heap overflow) — NVD — https://nvd.nist.gov/vuln/detail/CVE-2019-9500 — authoritative record for the WOWL heap overflow, CVSS 8.3 vector and adjacent-network vector; contributed the WOWL bug details and score. Credibility: primary-advisory. [2] NVD — CVE-2019-9501 (wl wlc_wpa_sup_eapol heap overflow) — NVD — https://nvd.nist.gov/vuln/detail/CVE-2019-9501 — the >32-byte vendor-IE overflow and CVSS 8.8 RCE branch. Credibility: primary-advisory. [3] NVD — CVE-2019-9502 (wl wlc_wpa_plumb_gtk heap overflow) — NVD — https://nvd.nist.gov/vuln/detail/CVE-2019-9502 — the >164-byte GTK/IE overflow during EAPOL parsing and CVSS 8.8 vector. Credibility: primary-advisory. [4] NVD — CVE-2019-9503 (brcmfmac is_wlc_event_frame validation bypass) — NVD — https://nvd.nist.gov/vuln/detail/CVE-2019-9503 — the event-frame validation bypass (scoped to USB bus, e.g. a Wi-Fi dongle), CWE-20, CVSS 8.3 vector AV:A/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H (CERT/CC alternative 7.9 with UI:R), and the fixing commit reference. Credibility: primary-advisory. [5] VU#166939 — Broadcom WiFi chipset drivers contain multiple vulnerabilities — CERT/CC (Carnegie Mellon SEI) — https://www.kb.cert.org/vuls/id/166939/ — coordinating note tying all four CVEs together, naming the vulnerable functions, the adjacent-network/RCE-or-DoS impact, timeline dates, and the affected-vendor list. Credibility: primary-advisory. [6] Microsoft Security Advisory ADV190017 — Microsoft HoloLens Remote Code Execution Vulnerabilities — MSRC — https://msrc.microsoft.com/en-us/security-guidance/advisory/ADV190017 — establishes HoloLens applicability (unauthenticated proximate attacker → DoS or code execution via the Broadcom chipset) and the June 2019 firmware remediation. Credibility: primary-advisory. [7] Reverse-engineering Broadcom wireless chipsets — Quarkslab (Hugues Anguelkov) — https://blog.quarkslab.com/reverse-engineering-broadcom-wireless-chipsets.html — original researcher writeup: RE methodology, vulnerable firmware functions, malicious-AP / oversized-GTK / crafted-SSID triggers, SoftMAC-vs-FullMAC landing, SDIO exemption, and the DoS-likely / RCE-hard assessment. Credibility: researcher-primary. [8] Broadcom WiFi Driver Flaws Expose Computers, Phones, IoT to RCE Attacks — BleepingComputer — https://www.bleepingcomputer.com/news/security/broadcom-wifi-driver-flaws-expose-computers-phones-iot-to-rce-attacks/ — reputable press summary of the four CVEs, the Quarkslab discovery, broad device exposure, and RCE/DoS framing. Credibility: reputable-press.