CVE-2026-68192

The core issue in CVE-2026-68192 isn't simply a missing NULL statement — it's a state management failure in brcmf_pcie_release_scratchbuffers(), which can be invoked from two distinct teardown contexts (the reset callback and the PCI remove path) without any tracking of whether buffers have already been released. This creates a double-free race window when reset teardown interleaves with removal. The fix is straightforward: NULL the pointers after freeing in release_scratchbuffers(), following the pattern already used in release_ringbuffers() within the same driver. That sibling function correctly nullifies its pointers on release, making the omission in release_scratchbuffers() a case of pattern drift rather than novel oversight — a known-safe idiom existed meters away but wasn't propagated. After applying the patch, treat this as a tripwire for a systematic audit. The question isn't whether other buffer-release functions in this driver lack idempotent semantics — it's which ones. Manually-implemented DMA buffer teardowns that don't wrap dma_free_coherent() with pointer-NULLing are the attack surface. Audit every release function in the brcmfmac PCIe driver family, not just the one named in this CVE. One practical concern: static analysis found this bug, which means the reset-then-remove sequence isn't exercised in existing test harnesses. After patching, verify your kernel's test coverage actually triggers this code path — otherwise you're flying blind on regression confirmation.

Reviewed through automated stages and approved by a human before publication.