Look up another CVE · open CVE-2026-68192 in the interactive tracker
CVE-2026-68192
wifi: brcmfmac: make release_scratchbuffers idempotent
Published 2026-08-10 (2 months ago) by the Linux kernel CNA. Subsystem drivers/net. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-68192 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixedDLA-4777-1 · 2026-09-08 · text | 6.1.187-1 | Update the kernel and reboot. DLA-4777-1 shipped the fix on 2026-09-08, in 6.1.187-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixed | 6.12.101-1 | Update the kernel and reboot. Fixed in 6.12.101-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.1.6-1 | Update the kernel and reboot. Fixed in 7.1.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.6-1 | Update the kernel and reboot. Fixed in 7.1.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4745-1 · 2026-08-18 · text | 6.12.101-1~deb12u1 | Update the kernel and reboot. DLA-4745-1 shipped the fix on 2026-08-18, in 6.12.101-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
brcmf_pcie_release_scratchbuffers() frees the shared.scratch and shared.ringupd DMA buffers with dma_free_coherent() but does not clear the pointers afterwards, unlike the sibling release_ringbuffers() which NULLs commonrings/flowrings/idxbuf on release. Both the bus_reset .reset callback (brcmf_pcie_reset) and brcmf_pcie_remove() call release_scratchbuffers. When reset teardown has run before removal, remove's own teardown would call dma_free_coherent() a second time on the already-freed DMA allocation. NULL the pointers after free, matching release_ringbuffers(), so a later release observes that the allocation has already been released. This patch makes repeated sequential release safe; the reset-work lifetime is handled separately by the following patch. This issue was found by an in-house static analysis tool.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
- What this is
- BROADCOM BRCM80211 IEEE802.11 WIRELESS DRIVERSMAINTAINERS section matched on drivers/net/wireless/broadcom/brcm80211/ · linux-wireless@vger.kernel.org · Supported
- Kernel module
- brcmfmac
Check it on the machine
grep -wE 'CONFIG_BRCMFMAC|CONFIG_BRCMFMAC_PCIE|CONFIG_BRCMSMAC|CONFIG_WLAN|CONFIG_WLAN_VENDOR_BROADCOM' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w brcmfmacPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookwormMnot built on amd64/cloud-amd64, arm64/cloud-arm64
- trixieMnot built on amd64/cloud-amd64, arm64/cloud-arm64, armel/rpi, s390x/s390x
- forky, sidMnot built on amd64/cloud-amd64, arm64/cloud-arm64, s390x/s390x
- bookworm · linux-6.12Mnot built on amd64/cloud-amd64, arm64/cloud-arm64
- M
- a module where it is built at all; some flavours do not build it
- Build switches
- CONFIG_BRCMFMAC, CONFIG_BRCMFMAC_PCIE, CONFIG_BRCMSMAC, CONFIG_WLAN, CONFIG_WLAN_VENDOR_BROADCOM
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-08-10 (2 months ago)source
- CVSS
- 8.8 high
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- adjacent network (AV:A)source
- EPSS
- 0.41%, higher than 33.4% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- drivers/net
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 5.2 | 5.10.265 | 81c58a206d1d |
| 5.2 | 5.15.216 | 382ee00b2d1e |
| 5.2 | 6.1.183 | 739b686aecdb |
| 5.2 | 6.6.148 | b7d1d8cb1bdc |
| 5.2 | 6.12.101 | 5a045c2f0fbf |
| 5.2 | 6.18.42 | 044fca8f45ba |
| 5.2 | 7.1.6 | 0ca80328df23 |
| 5.2 | 7.2 | 538c51e9d124 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4777-1 | 2026-09-08 | bookworm 6.1.187-1 | tracker |
| DLA-4745-1 | 2026-08-18 | bookworm 6.12.101-1~deb12u1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:AAttack vector, adjacent network
- The flaw is reached during brcmfmac PCIe bus reset/teardown after firmware halt; brcmf_fw_crashed() is invoked from the threaded IRQ handler on BRCMF_D2H_DEV_FWHALT mailbox data from the WiFi firmware, which an adjacent attacker can trigger with crafted over-the-air WiFi traffic to crash the dongle.
- AC:LAttack complexity, low
- An attacker who induces firmware halt controls the reset sequence; brcmf_pcie_reset() always frees scratch buffers first and a later brcmf_pcie_remove() or failed brcmf_pcie_setup() teardown calls release_scratchbuffers() again on the same stale pointers, making the double-free deterministic without races they cannot influence.
- PR:NPrivileges required, none
- No host privileges are required because crashing Broadcom FullMAC firmware via adjacent WiFi frames reaches brcmf_fw_crashed() without authentication, CAP_NET_ADMIN, or local access; the debugfs reset path is root-only but is not needed for the highest-impact attack scenario.
- UI:NUser interaction, none
- Exploitation only requires a victim with an active brcmfmac PCIe WiFi interface within RF range; no victim click, file open, driver unload, or other explicit user action is needed beyond normal always-on WiFi operation on laptops and embedded hosts using Broadcom PCIe FullMAC chips.
- S:UScope, unchanged
- The vulnerability corrupts kernel DMA/page-allocator state and enables host kernel privilege escalation within the same security authority; it does not cross VM, container, or IOMMU boundaries, so scope remains unchanged.
- C:HConfidentiality impact, high
- Calling dma_free_coherent() twice on the same scratch and ringupd DMA allocations is a double-free of kernel coherent memory; this allocator-metadata corruption can be leveraged for arbitrary kernel memory disclosure even when full exploitation is not attempted, per kernel CVSS guidance for memory corruption.
- I:HIntegrity impact, high
- Double-free of dma_alloc_coherent buffers corrupts the kernel DMA/page heap freelist, enabling attacker-controlled reallocation and arbitrary kernel writes or control-flow hijack on systems with BRCMFMAC_PCIE enabled and a reachable Broadcom PCIe FullMAC wireless device.
- A:HAvailability impact, high
- Re-freeing already released DMA-coherent allocations during driver reset or removal typically causes immediate kernel BUG/oops/panic or fatal allocator corruption during teardown, guaranteeing severe host availability loss on affected Broadcom PCIe WiFi systems even when code execution is not achieved.