Cloudanix VulnDB

CVE-2026-68403

None

CVSS

—

EPSS

0.2%

Published

Aug 10, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A setup error in the Linux kernel's handling of certain WiFi chips can let an attacker crash the machine or potentially run code when hardware loading fails in a specific way.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
High
Impact
Denial Of Service
Component
OS kernel
Class
Use After Free
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free in brcmfmac SDIO driver: brcmf_sdio_probe stores bus pointer then attempts alloc_ordered_workqueue; failure jumps to brcmf_sdio_remove which unconditionally cancels the uninitialized bus->datawork work item.

Why it matters to the business

Low-probability kernel instability or potential code execution on Linux systems using Broadcom SDIO WiFi; no known exploitation, low and declining EPSS, and not used in ransomware or KEV campaigns reduces operational urgency.

How an attack unfolds

An attacker forces alloc_ordered_workqueue failure inside brcmf_sdio_probe (via resource exhaustion or synthetic hardware fault), causing the error path to invoke brcmf_sdio_remove and cancel an uninitialized work item, triggering the use-after-free condition.

How to fix it

Apply upstream Linux kernel patches that move INIT_WORK(&bus->datawork) before the first failure path reaching brcmf_sdio_remove; rebuild and deploy updated kernel images to all affected systems.

How to confirm the fix worked

Review probe error paths in brcmf_sdio.c to confirm work item initialization precedes any goto to the remove handler; reproduce allocation failure with fault injection and verify absence of DEBUG_OBJECTS warnings on work drain.

Typical attack path

  1. Load or probe brcmfmac SDIO device
  2. Trigger failure of alloc_ordered_workqueue before INIT_WORK(&bus->datawork)
  3. Execute brcmf_sdio_remove cleanup path
  4. Cancel uninitialized datawork leading to use-after-free

How to detect it

Search kernel logs and dmesg for DEBUG_OBJECTS reports containing brcmf_sdio_probe and brcmf_sdio_remove stack frames during module load or device probe; correlate with workqueue allocation failures.

What your security team should do

  • Prioritize kernel updates on systems exposing Broadcom SDIO WiFi
  • Enable DEBUG_OBJECTS and monitor for invalid work-item warnings during driver probe
  • Restrict physical or virtual SDIO device attachment to trusted hardware only

The record

In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: initialize SDIO data work before cleanup brcmf_sdio_probe() stores the newly allocated bus in sdiodev->bus before allocating the ordered workqueue. If that allocation fails, the function jumps to fail and calls brcmf_sdio_remove(). brcmf_sdio_remove() unconditionally cancels bus->datawork. Initialize the work item before the first failure path that can reach brcmf_sdio_remove(), so the cleanup path always observes a valid work object. This issue was found by our static analysis tool and then confirmed by manual review of the probe error path and the remove-time work drain. The problem pattern is an early setup failure that reaches a cleanup helper which cancels an embedded work item before its initializer has run. A QEMU PoC forced alloc_ordered_workqueue() to fail at the same point in brcmf_sdio_probe(), before INIT_WORK(&bus->datawork) is reached. The resulting fail path calls brcmf_sdio_remove(), and DEBUG_OBJECTS reports the invalid work drain with brcmf_sdio_probe() and brcmf_sdio_remove() in the stack.

Affected packages

Ecosystem Package Introduced Fixed