CVE-2026-68192 in Linux
Summary
by MITRE • 08/10/2026
In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmfmac: make release_scratchbuffers idempotent
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/10/2026
The vulnerability in question affects the brcmfmac driver within the Linux kernel, specifically impacting the Broadcom PCIe wireless network adapter implementation. This issue manifests as a potential double-free condition during device teardown operations, where DMA buffer memory management becomes inconsistent across different cleanup paths. The problem occurs in the brcmf_pcie_release_scratchbuffers() function which handles freeing shared.scratch and shared.ringupd DMA buffers using dma_free_coherent() without clearing the associated pointers afterward. This behavior creates a discrepancy with the sibling function release_ringbuffers() which properly NULLs the commonrings/flowrings/idxbuf pointers upon resource release, establishing an inconsistent memory management pattern that can lead to undefined behavior.
The operational impact of this vulnerability becomes significant when considering the device reset and removal sequences that occur during normal operation or error conditions. Both the bus_reset .reset callback function brcmf_pcie_reset and the brcmf_pcie_remove() function invoke release_scratchbuffers(), creating a scenario where the same DMA buffer memory can be freed twice if reset teardown operations complete before the removal process begins. This double-free condition represents a classic memory safety issue that could potentially lead to system instability, memory corruption, or in worst-case scenarios, arbitrary code execution. The vulnerability particularly affects systems utilizing Broadcom PCIe wireless adapters where device reset and removal operations may overlap or occur in sequence.
This specific flaw aligns with CWE-415: Double Free and CWE-787: Out-of-bounds Write categories, representing a memory management error that violates proper resource cleanup procedures. The issue demonstrates poor defensive programming practices where resource deallocation does not properly account for potential multiple invocation scenarios, creating a race condition in the cleanup sequence. From an ATT&CK perspective, this vulnerability could be leveraged as part of a broader exploitation chain targeting kernel memory corruption, potentially enabling privilege escalation or denial-of-service conditions. The static analysis tool that identified this issue highlights the importance of automated code review in detecting subtle memory management errors that may not surface during normal testing procedures.
The patch addressing this vulnerability implements a straightforward but critical fix by NULLing the pointers after calling dma_free_coherent() within release_scratchbuffers(), matching the behavior of the release_ringbuffers() function. This idempotent approach ensures that subsequent calls to release_scratchbuffers() will recognize that resources have already been freed and avoid attempting to free already-released memory. The solution maintains consistency with established kernel programming practices for resource management and provides a robust defense against repeated sequential cleanup operations. The fix specifically addresses the lifetime management issue mentioned in the description, ensuring that reset operations do not interfere with subsequent removal procedures while maintaining proper memory state tracking throughout the device lifecycle.
The broader implications of this vulnerability extend beyond immediate memory safety concerns to highlight systemic issues in kernel driver development practices. It demonstrates how seemingly minor inconsistencies in memory management can create significant security risks when multiple code paths interact with shared resources. The fix reinforces the principle that all resource deallocation operations should properly invalidate pointers and maintain consistent state across different cleanup functions, preventing potential exploitation through memory corruption attacks. This vulnerability serves as a reminder of the critical importance of defensive programming in kernel space where resource management errors can have far-reaching consequences for system stability and security.