CVE-2025-40321: Linux kernel · wifi: brcmfmac: fix crash while sending Action Frames in standalone AP Mode
Affects Linux kernelSource GCVE Database
Not known to be exploited · fixed in 5.15.0-1103.110~20.04.1 : update Linux kernel when convenient.
Data as of 26 Oct 2026, 10:12 UTC
Rated by Threat Radar · No CVSS score from NVD or the CNA
- EPSS
- 0.2% chance of exploitation in 30 days – higher than 9% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in 5.15.0-1103.110~20.04.1, 5.15.0-1110.119~20.04.1, 5.15.0-1103.112~20.04.1 +69
Exploitation evidence
Disclosed: evidence found.
CVE published 8 Dec 2025
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
Upgrade to a fixed release listed under Affected software.
Patches and advisories
- ubuntu.com/security/notices/USN-8029-1 (opens in a new tab)
- ubuntu.com/security/notices/USN-8030-1 (opens in a new tab)
- ubuntu.com/security/notices/USN-8029-2 (opens in a new tab)
- ubuntu.com/security/notices/USN-8048-1 (opens in a new tab)
- ubuntu.com/security/notices/USN-8029-3 (opens in a new tab)
- ubuntu.com/security/notices/USN-8095-1 (opens in a new tab)
- ubuntu.com/security/notices/USN-8096-1 (opens in a new tab)
- ubuntu.com/security/notices/USN-8100-1 (opens in a new tab)
- ubuntu.com/security/notices/USN-8095-2 (opens in a new tab)
- ubuntu.com/security/notices/USN-8096-2 (opens in a new tab)
- ubuntu.com/security/notices/USN-8095-3 (opens in a new tab)
- ubuntu.com/security/notices/USN-8096-3 (opens in a new tab)
Affected software
| Product | Affected | Fixed in |
|---|---|---|
Ubuntu 25.10linuxpkg:deb/ubuntu/linux?arch=source&distro=questingOther threats | Affected
| Fixed in
|
Ubuntu 25.10linux-awspkg:deb/ubuntu/linux-aws?arch=source&distro=questingOther threats | Affected
| Fixed in
|
Ubuntu 25.10linux-azurepkg:deb/ubuntu/linux-azure?arch=source&distro=questingOther threats | Affected
| Fixed in
|
Ubuntu 25.10linux-azure-fdepkg:deb/ubuntu/linux-azure-fde?arch=source&distro=questingOther threats | Affected
| Fixed in– |
Ubuntu 25.10linux-gcppkg:deb/ubuntu/linux-gcp?arch=source&distro=questingOther threats | Affected
| Fixed in
|
Ubuntu 25.10linux-oraclepkg:deb/ubuntu/linux-oracle?arch=source&distro=questingOther threats | Affected
| Fixed in
|
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
Description
In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix crash while sending Action Frames in standalone AP Mode Currently, whenever there is a need to transmit an Action frame, the brcmfmac driver always uses the P2P vif to send the "actframe" IOVAR to firmware. The P2P interfaces were available when wpa_supplicant is managing the wlan interface. However, the P2P interfaces are not created/initialized when only hostapd is managing the wlan interface. And if hostapd receives an ANQP Query REQ Action frame even from an un-associated STA, the brcmfmac driver tries to use an uninitialized P2P vif pointer for sending the IOVAR to firmware. This NULL pointer dereferencing triggers a driver crash. [ 1417.074538] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [...] [ 1417.075188] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [...] [ 1417.075653] Call trace: [ 1417.075662] brcmf_p2p_send_action_frame+0x23c/0xc58 [brcmfmac] [ 1417.075738] brcmf_cfg80211_mgmt_tx+0x304/0x5c0 [brcmfmac] [ 1417.075810] cfg80211_mlme_mgmt_tx+0x1b0/0x428 [cfg80211] [ 1417.076067] nl80211_tx_mgmt+0x238/0x388 [cfg80211] [ 1417.076281] genl_family_rcv_msg_doit+0xe0/0x158 [ 1417.076302] genl_rcv_msg+0x220/0x2a0 [ 1417.076317] netlink_rcv_skb+0x68/0x140 [ 1417.076330] genl_rcv+0x40/0x60 [ 1417.076343] netlink_unicast+0x330/0x3b8 [ 1417.076357] netlink_sendmsg+0x19c/0x3f8 [ 1417.076370] __sock_sendmsg+0x64/0xc0 [ 1417.076391] ____sys_sendmsg+0x268/0x2a0 [ 1417.076408] ___sys_sendmsg+0xb8/0x118 [ 1417.076427] __sys_sendmsg+0x90/0xf8 [ 1417.076445] __arm64_sys_sendmsg+0x2c/0x40 [ 1417.076465] invoke_syscall+0x50/0x120 [ 1417.076486] el0_svc_common.constprop.0+0x48/0xf0 [ 1417.076506] do_el0_svc+0x24/0x38 [ 1417.076525] el0_svc+0x30/0x100 [ 1417.076548] el0t_64_sync_handler+0x100/0x130 [ 1417.076569] el0t_64_sync+0x190/0x198 [ 1417.076589] Code: f9401e80 aa1603e2 f9403be1 5280e483 (f9400000) Fix this, by always using the vif corresponding to the wdev on which the Action frame Transmission request was initiated by the userspace. This way, even if P2P vif is not available, the IOVAR is sent to firmware on AP vif and the ANQP Query RESP Action frame is transmitted without crashing the driver. Move init_completion() for "send_af_done" from brcmf_p2p_create_p2pdev() to brcmf_p2p_attach(). Because the former function would not get executed when only hostapd is managing wlan interface, and it is not safe to do reinit_completion() later in brcmf_p2p_tx_action_frame(), without any prior init_completion(). And in the brcmf_p2p_tx_action_frame() function, the condition check for P2P Presence response frame is not needed, since the wpa_supplicant is properly sending the P2P Presense Response frame on the P2P-GO vif instead of the P2P-Device vif. [Cc stable]
References
- ubuntu.com/security/CVE-2025-40321 (opens in a new tab)
- cve.org/CVERecord?id=CVE-2025-40321 (opens in a new tab)
- git.kernel.org/linus/3776c685ebe5f43e9060af06872661de55e80b9a (opens in a new tab)
- git.kernel.org/stable/c/3776c685ebe5f43e9060af06872661de55e80b9a (opens in a new tab)
- git.kernel.org/stable/c/55f60a72a178909ece4e32987e4c642ba57e1cf4 (opens in a new tab)
- git.kernel.org/stable/c/64e3175d1c8a3bea02032e7c9d1befd5f43786fa (opens in a new tab)
- git.kernel.org/stable/c/a6eed58249e7d60f856900e682992300f770f64b (opens in a new tab)
- git.kernel.org/stable/c/c2b0f8d3e7358c33d90f0e62765d474f25f26a45 (opens in a new tab)
- git.kernel.org/stable/c/c863b9c7b4e9af0b7931cb791ec91971a50f1a25 (opens in a new tab)
- git.kernel.org/stable/c/dbc7357b6aae686d9404e1dd7e2e6cf92c3a1b5a (opens in a new tab)
- git.kernel.org/stable/c/e1fc9afcce9139791260f962541282d47fbb508d (opens in a new tab)
- ubuntu.com/security/notices/USN-8029-1 (opens in a new tab)
- ubuntu.com/security/notices/USN-8030-1 (opens in a new tab)
- ubuntu.com/security/notices/USN-8029-2 (opens in a new tab)
- ubuntu.com/security/notices/USN-8048-1 (opens in a new tab)
- ubuntu.com/security/notices/USN-8029-3 (opens in a new tab)
- ubuntu.com/security/notices/USN-8095-1 (opens in a new tab)
- ubuntu.com/security/notices/USN-8096-1 (opens in a new tab)
- ubuntu.com/security/notices/USN-8100-1 (opens in a new tab)
- ubuntu.com/security/notices/USN-8095-2 (opens in a new tab)