CVE-2026-68192 Fixes Linux Broadcom PCIe Wi-Fi Double-Free

For Windows administrators, this is not a Windows Wi-Fi driver vulnerability and it does not map to a Microsoft KB. It belongs in Linux kernel patch management: dual-boot endpoints, Linux laptops using supported Broadcom PCIe FullMAC adapters, appliances, virtual-machine hosts with device passthrough, and custom WSL 2 kernel deployments are the relevant estate. Native Windows installations using Broadcom’s Windows driver stack are outside the affected code path.

The important finding in the published record is also what it does not establish. NVD has assigned no CVSS score, no CWE category, and no exploitability assessment as of August 11, 2026; no independent exploit report or vendor advisory describing active abuse was located. Treat this as a kernel stability and memory-safety update that warrants normal security patching, rather than evidence of a remotely exploitable Wi-Fi compromise.

The bug is a repeated cleanup of DMA buffers​

The affected code sits in

, the PCIe transport implementation for the

driver. Linux Wireless documentation describes

as Broadcom’s FullMAC wireless driver family, with PCIe support covering specific Broadcom chipsets; this is not a finding against every Broadcom Wi-Fi device or every Linux wireless driver.

The vulnerable routine,

, releases two DMA-coherent allocations:

and

. DMA-coherent buffers are memory regions allocated for shared use by the CPU and a hardware device, so teardown must ensure the allocation is freed once and only once.

Before the fix, the routine called

but did not set either pointer to

. That left a stale address in the driver’s state. A later cleanup call could therefore mistake an already-freed allocation for a live one and submit it for release again.

The bug is straightforward when expressed as a sequence:

1. The PCIe Wi-Fi device enters the driver’s reset teardown path.
2. brcmf_pcie_reset() invokes the scratch-buffer release routine and frees the DMA allocations.
3. The pointers remain non-null after the free.
4. The device is later removed and brcmf_pcie_remove() invokes the same release routine.
5. The driver attempts to free the old DMA allocations a second time.

The correction makes the release routine idempotent: after each buffer is freed, its pointer is cleared. Calling the routine again then observes that no allocation remains. Linux already followed that pattern in the nearby

routine, which clears its ring-buffer pointers during cleanup; the patch brings scratch-buffer handling into line with that existing design.

The fix addresses a sequential teardown flaw, not every reset race​

The wording of the CVE matters. The kernel.org description says the patch makes “repeated sequential release” safe, then explicitly says reset-work lifetime is handled by a following patch. That is a material boundary on what CVE-2026-68192 fixes.

In practical terms, this change prevents the same cleanup operation from releasing stale DMA pointers after an earlier cleanup completed. It does not, on its own, claim to solve every timing problem involving device reset work, driver removal, and concurrent activity. Administrators rebuilding kernels or selectively backporting commits should not interpret this one-line-style pointer cleanup as a complete audit of the reset/remove path.

That distinction also argues against cherry-picking this fix in isolation where a supported stable-kernel update is available. The Linux stable process often groups related driver-lifetime corrections across a maintenance series. Taking the maintained vendor kernel package gives administrators the surrounding fixes, configuration integration, and regression testing that a single source commit does not.

The CVE record says the defect was found by an in-house static analysis tool, not by an incident response team or a public proof of concept. Static analysis is particularly effective at finding cleanup asymmetries such as “free without nulling,” and this report looks like exactly that class of finding. It should be patched because double frees are memory-safety defects, but the record provides no basis for claiming that an attacker can reliably trigger it from Wi-Fi traffic.

Fixed kernels are already identified, but distro version strings are decisive​

NVD’s kernel.org-supplied affected-version data traces the bug back to Linux 5.2. It lists corrected releases in four maintained stable lines: Linux 6.6.148, Linux 6.12.101, Linux 6.18.42, and Linux 7.1.6. The mainline fix is recorded as present by Linux 7.2-rc5.

Those numbers are useful for source-built kernels and for teams following upstream stable releases directly. They are not enough to clear a distribution-managed machine. Ubuntu, Debian, Red Hat Enterprise Linux, SUSE Linux Enterprise, Amazon Linux, Android-derived systems, and embedded vendors routinely backport a security fix without replacing the visible base version with the upstream release number.

A host reporting a vendor kernel that begins with

, for example, may already contain the correction even when it is not literally running 6.6.148. Conversely, a system with a newer-looking downstream build should not be assumed safe solely from its prefix. The correct verification point is the distribution’s kernel changelog, security tracker, or package advisory for CVE-2026-68192, plus the installed package revision.

The NVD entry currently has no NIST-assigned CVSS vector or severity rating. That absence should not delay deployment where a vendor update is ready, but it does mean scanners and dashboards that prioritize only scored CVEs may initially bury the issue. Security operations teams should tag it as a Linux kernel driver remediation item rather than waiting for a severity field that may arrive later.

Windows endpoints need Linux inventory, not a Windows Update response​

Windows 11 and current Windows 10 systems do not use the Linux

source file for their native wireless stack. A Broadcom Wi-Fi adapter appearing in Device Manager does not, by itself, make a Windows endpoint affected by CVE-2026-68192. The vulnerability requires a Linux kernel running the

PCIe driver and reaching the specific reset-then-remove cleanup sequence.

WSL 2 deserves a narrower qualification. Microsoft documents that WSL 2 runs an actual Linux kernel inside a lightweight utility VM and that its kernel is serviced through WSL updates;

is the normal servicing command. But a standard WSL 2 instance ordinarily uses virtualized networking rather than binding the guest’s

driver to the host’s physical Broadcom PCIe wireless adapter.

The higher-risk Windows-adjacent cases are organizations that have overridden WSL’s default kernel through

, run custom kernels in Hyper-V or other local virtualization platforms, or use physical device passthrough in specialist deployments. Microsoft’s WSL configuration documentation permits a custom kernel path, which turns patch verification into the administrator’s responsibility. A custom WSL kernel built from an affected branch should be rebuilt or replaced with a kernel carrying the correction.

For ordinary Windows fleets, the operational response is simpler: do not hunt for a Microsoft Patch Tuesday entry. Instead, identify Linux systems attached to the fleet—developer dual-boot machines, WSL custom-kernel users, build agents, test racks, network appliances, and Linux VMs with hardware access—and check the kernel package supplied by each platform owner.

What administrators should do now​

Linux administrators should install the latest supported kernel package from their distribution or platform vendor, then reboot into it where the vendor’s process requires a restart. Teams maintaining custom kernels should confirm that their chosen stable line contains the equivalent of the kernel.org fix, rather than merely assuming a later distro branding number includes it.

For triage, the most relevant machines are those with all three conditions: a Linux kernel potentially based on an affected line, a Broadcom PCIe FullMAC adapter supported by

, and a workload where Wi-Fi reset, recovery, device removal, suspend/resume, or driver unload paths may be exercised. Systems using Ethernet only, unrelated wireless hardware, or

over another bus are not automatically implicated by this PCIe-specific CVE.

The immediate consequence is reliability as much as security: the faulty teardown can turn a reset followed by removal into a kernel memory-management failure. With the pointer-clearing fix present, the second cleanup sees an already-released state and exits safely—the small defensive change that should have been there before the driver’s reset path and remove path were allowed to converge.