CVE-2026-99061 in Linux
Summary
by MITRE • 10/23/2026
In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmfmac: fix P2P device removal race in brcmf_detach()
When the driver is removed while the user space process that created the P2P device (e.g. wpa_supplicant) is still exiting, the P2P device interface is removed twice and the kernel crashes.
The two paths are:
- wpa_supplicant, on exit, sends NL80211_CMD_DEL_INTERFACE for the P2P device. nl80211_del_interface() holds RTNL and the wiphy mutex and calls brcmf_p2p_del_vif(), which disables discovery and waits up to 1.5 s for BRCMF_E_IF_DEL. Then it calls brcmf_remove_interface(), which unregisters the wdev and frees the vif and the ifp.
- brcmf_detach() sets the bus down, so BRCMF_E_IF_DEL never arrives, and calls brcmf_remove_interface(ifp, false) for the same ifp. brcmf_p2p_ifp_removed() reads ifp->vif and then blocks on rtnl_lock(). When brcmf_p2p_del_vif() releases RTNL, it calls cfg80211_unregister_wdev() on the wdev that was already unregistered and freed.
The second list_del_rcu() of wdev->list faults on LIST_POISON2:
brcmfmac: brcmf_p2p_del_vif delete P2P vif brcmfmac: brcmf_p2p_deinit_discovery enter brcmfmac: brcmf_p2p_del_vif P2P: GO_NEG_PHASE status cleared brcmfmac: brcmf_detach Enter brcmfmac: brcmf_bus_change_state 1 -> 0 brcmfmac: brcmf_remove_interface Enter, bsscfgidx=1, ifidx=0 brcmfmac: brcmf_del_if Enter, bsscfgidx=1, ifidx=0 brcmfmac: brcmf_p2p_ifp_removed P2P: device interface removed [1.5 s later, brcmf_p2p_del_vif() timed out]
brcmfmac: brcmf_remove_interface Enter, bsscfgidx=1, ifidx=0 brcmfmac: brcmf_del_if Enter, bsscfgidx=1, ifidx=0 brcmfmac: brcmf_p2p_ifp_removed P2P: device interface removed Unable to handle kernel paging request at virtual address dead000000000122 Internal error: Oops: 96000044 [#1] PREEMPT_RT SMP
pc : _cfg80211_unregister_wdev+0x6c/0x264 [cfg80211]
Call trace: _cfg80211_unregister_wdev+0x6c/0x264 [cfg80211]
cfg80211_unregister_wdev+0x10/0x1c [cfg80211]
brcmf_p2p_ifp_removed+0x84/0xb0 [brcmfmac]
brcmf_remove_interface+0x1f4/0x254 [brcmfmac]
brcmf_detach+0x88/0x180 [brcmfmac]
brcmf_sdio_remove+0x90/0x7b0 [brcmfmac]
brcmf_sdiod_remove+0x20/0xa0 [brcmfmac]
brcmf_ops_sdio_remove+0xbc/0x12c [brcmfmac]
sdio_bus_remove+0x38/0x144 device_release_driver_internal+0x1e8/0x2c0 device_release_driver+0x14/0x20 brcmf_sdio_bus_remove+0x2c/0x40 [brcmfmac]
brcmf_fwvid_unregister_vendor+0xd8/0x170 [brcmfmac]
__exit_compat+0x18/0x418 [brcmfmac_cyw]
__arm64_sys_delete_module+0x1ac/0x244
The log was taken with debug=0x406 on an i.MX 8M Plus board with a CYW55513 (Sona IF513) on SDIO. The driver is the Ezurio backport of brcmfmac from v6.18.22 on a 5.4-rt kernel. The code involved is the same in mainline.
To reproduce:
1. Start wpa_supplicant on wlan0 and let it associate. It creates the P2P device (iw dev shows "type P2P-device"). 2. Stop wpa_supplicant and remove the driver without waiting for wpa_supplicant to exit:
kill $(pidof wpa_supplicant) rmmod brcmfmac_cyw brcmfmac
The crash is reproducible on that board.
For the interface without a netdev (the P2P device), take RTNL and the wiphy mutex in brcmf_detach() before reading iflist, and remove it with locked=true. If brcmf_p2p_del_vif() runs first, brcmf_detach() finds the slot empty. If brcmf_detach() runs first, nl80211 does not find the wdev any more. The interfaces with a netdev are removed as before, because brcmf_del_if() takes RTNL on its own for the primary interface.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/23/2026
The Linux kernel wireless driver for Broadcom chipsets, specifically brcmfmac, contains a critical race condition vulnerability within the device detachment and peer-to-peer interface removal logic. This flaw manifests when the kernel module is unloaded while an associated user-space process, such as wpa_supplicant, is in the midst of exiting and attempting to delete its created P2P device interfaces. The core issue stems from insufficient synchronization between two distinct code paths that both attempt to remove the same virtual interface structure without proper mutual exclusion or state checking. One path originates from the netlink subsystem when user-space sends an NL80211_CMD_DEL_INTERFACE command, triggering a sequence in nl80211_del_interface that holds the RTNL lock and wiphy mutex before calling brcmf_p2p_del_vif. This function disables discovery mechanisms and waits for hardware acknowledgment of interface deletion before proceeding to unregister the wireless device structure and free associated memory resources. The second path is initiated by the driver's detach routine, which unloads the module and sets the bus state down, potentially preventing the expected hardware event from arriving. Consequently, brcmf_detach proceeds to call brcmf_remove_interface for the same interface pointer without verifying if it has already been removed by the user-space triggered path.
This lack of atomicity leads to a double-free scenario where kernel memory management structures are corrupted. Specifically, when both paths execute concurrently or in an interleaved manner due to timing windows, the second invocation attempts to unregister and free resources that have already been deallocated by the first invocation. The technical evidence points to a use-after-free condition affecting the wireless device list structure. When brcmf_p2p_ifp_removed is invoked during the detach process after the interface has already been unregistered, it attempts to manipulate the wdev->list which contains poisoned memory values indicating prior deallocation. This results in an immediate kernel panic with a paging request fault at a virtual address marked as dead000000000122, confirming that the pointer references freed or invalid memory regions. The crash occurs within _cfg80211_unregister_wdev, which is called by brcmf_p2p_ifp_removed during the second removal attempt. This type of vulnerability allows for local denial-of-service attacks where a privileged user can trigger system instability simply by managing wireless interfaces and driver modules concurrently.
From a security classification perspective, this flaw aligns with CWE-416, Use After Free, as it involves accessing memory after it has been freed, leading to undefined behavior and potential exploitation vectors beyond simple crashes if the timing allows for heap grooming or other advanced attack techniques. In terms of offensive security frameworks like MITRE ATT&CK, this vulnerability facilitates Local Privilege Escalation via Denial of Service (T1053) when exploited by a local user with sufficient permissions to load and unload kernel modules. The impact is severe as it compromises the stability and availability of the entire operating system rather than just the wireless subsystem. System administrators and developers must recognize that race conditions in driver detach routines are particularly dangerous because they often occur during routine maintenance or ungraceful shutdowns, making them difficult to reproduce consistently but highly impactful when triggered.
The resolution involves implementing strict locking mechanisms within brcmf_detach() to ensure exclusive access to the interface list before performing removal operations. The fix requires acquiring both the RTNL lock and the wiphy mutex prior to checking iflist for P2P devices without network device structures, ensuring that any concurrent deletion attempts by user-space are serialized or detected as already completed. By setting locked=true during the removal process in brcmf_detach(), the driver guarantees atomicity of the interface state transition. If the user-space path executes first and removes the interface, the detach routine will find the slot empty and skip redundant operations. Conversely, if the detach routine runs first, it successfully removes the interface, preventing nl80211 from finding a valid wdev to unregister. This synchronization strategy eliminates the race window entirely for P2P devices while maintaining existing behavior for standard interfaces that already possess their own locking mechanisms within brcmf_del_if. Mitigation strategies include applying this kernel patch immediately in environments where wireless drivers are frequently loaded and unloaded, or restricting module unloading privileges to trusted system administrators only until the update is deployed.