CyberSecBulletin
CVE-2026-64586NVD status: Received

Linux: Use After Free

Published Updated By the CyberSecBulletin desk

CVE-2026-64586 is a high-severity use after free vulnerability in Linux, with a CVSS 3.1 base score of 8.8 out of 10. It can be exploited from the same local network by an unauthenticated attacker, without any action from a user. The record lists versions 9dfb09cb0abbf92a06f93e0715e163aa188a84da, 4824e3bcc68f8d678b409039d1bb48c7b5ea73dc, 61127dd20920bf28460a1609aabb0dafa2f54fac as the first without the flaw, so updating Linux to one of those releases or later removes the exposure. There is no confirmed exploitation so far. EPSS estimates a 0.25% chance of exploitation within 30 days, which is low compared with other CVEs.

Next patch cycle

High severity with no evidence of exploitation so far.

What to do

  1. Update Linux to 9dfb09cb0abbf92a06f93e0715e163aa188a84da or 4824e3bcc68f8d678b409039d1bb48c7b5ea73dc or 61127dd20920bf28460a1609aabb0dafa2f54fac or c268331845ee00dbdbccb000826bb612dff2bee7, whichever matches your release line, or a later version.

Affected products and versions

VendorProductAffected versionsFixed in
LinuxLinux4684997d9eea29380000e062755aa6d368d789a3 up to, but not including, 9dfb09cb0abbf92a06f93e0715e163aa188a84da; 4684997d9eea29380000e062755aa6d368d789a3 up to, but not including, 4824e3bcc68f8d678b409039d1bb48c7b5ea73dc; 4684997d9eea29380000e062755aa6d368d789a3 up to, but not including, 61127dd20920bf28460a1609aabb0dafa2f54fac; 4684997d9eea29380000e062755aa6d368d789a3 up to, but not including, c268331845ee00dbdbccb000826bb612dff2bee7; 4684997d9eea29380000e062755aa6d368d789a3 up to, but not including, e3815d1ffbb9be4f1605ddc3b427557893461683; 4684997d9eea29380000e062755aa6d368d789a3 up to, but not including, 02d378828af8bb74f6c2f4d2bee3c77cf16c861e; 4684997d9eea29380000e062755aa6d368d789a3 up to, but not including, 177a25be1195f8bdc6160ba5f1a5699f7041c985; 4684997d9eea29380000e062755aa6d368d789a3 up to, but not including, 43b25879f004c98defa2776bedc6ca4763c51945; and 1 more ranges9dfb09cb0abbf92a06f93e0715e163aa188a84da, 4824e3bcc68f8d678b409039d1bb48c7b5ea73dc, 61127dd20920bf28460a1609aabb0dafa2f54fac, c268331845ee00dbdbccb000826bb612dff2bee7, e3815d1ffbb9be4f1605ddc3b427557893461683, 02d378828af8bb74f6c2f4d2bee3c77cf16c861e

Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.

How the severity score breaks down

Attack vector
AdjacentThe attacker must be on the same local network segment.
Attack complexity
LowNo special conditions are needed; the attack works reliably.
Privileges required
NoneNo account or login is needed.
User interaction
NoneNo action by a victim is required.
Scope
UnchangedImpact stays within the vulnerable component.
Confidentiality
HighAll data handled by the component can be read.
Integrity
HighData or code can be modified at will.
Availability
HighThe component can be taken down completely.

Vector: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Scored by CNA.

Official description

In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: drain bus_reset work on device removal brcmf_fw_crashed() and the debugfs "reset" entry both schedule drvr->bus_reset, whose callback recovers drvr through container_of() and dereferences it. The removal path frees drvr (brcmf_free -> wiphy_free) without draining the work, so a bus_reset callback pending or running during removal can outlive drvr. Cancellation cannot live in brcmf_detach() or brcmf_free(): the work callback reaches teardown through the bus .reset op (PCIe brcmf_pcie_reset -> brcmf_detach; SDIO brcmf_sdio_bus_reset -> brcmf_sdiod_remove -> brcmf_free), so cancelling there would wait for the running work and deadlock. Add a per-bus mutex (bus_reset_lock) and route all arming through brcmf_bus_schedule_reset(), which under the lock skips when the bus is marked removing. Each bus remove entry calls brcmf_bus_cancel_reset_work(), which under the same lock sets removing and cancels the work. Holding the mutex across cancel_work_sync() makes the set-removing + drain step atomic. Every producer reaches the arming path from process context -- the PCIe firmware-halt notification runs in the threaded IRQ handler (brcmf_pcie_isr_thread) and the SDIO hostmail path runs from the data workqueue -- so the mutex is taken only in sleepable contexts. Where applicable the remove entry first stops the firmware-crash producer: on PCIe mask the mailbox and synchronize_irq; on SDIO unregister the bus interrupt and cancel the data worker, which also reports firmware halts through brcmf_fw_crashed(). The mutex is initialized at bus allocation. The SDIO suspend power-off path frees drvr through the same brcmf_sdiod_remove() and takes the same lock; resume re-allows the work only on a successful re-probe. Also guard brcmf_fw_crashed() against a NULL bus_if/drvr: it can fire before brcmf_attach() wires up drvr, and it dereferences drvr (bphy_err/brcmf_dev_coredump) before reaching the arming gate. The bus_reset work is shared across buses, so the drain is applied to every remove path: PCIe (the .reset op introduced by the Fixes commit), SDIO (arms the same work through brcmf_fw_crashed()), and USB (via the debugfs "reset" entry). cancel_work_sync() drains a running or pending bus_reset work item before removal frees drvr, and patch 1/2 makes the scratch-buffer release safe when reset teardown has already released those DMA buffers. This patch fixes the lifetime of the bus_reset work item itself. It does not attempt to address the separate, pre-existing lifetime of the asynchronous firmware completion started by the PCIe reset path. That callback needs its own lifetime/ownership protocol and is being tracked separately. This issue was found by an in-house static analysis tool.

Source: the CVE record as published by its numbering authority, via NVD and CVE.org.

The underlying weakness: Use After Free

The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory belongs to the code that operates on the new pointer.

How developers prevent this class of flaw

  • Choose a language that provides automatic memory management.
  • When freeing pointers, be sure to set them to NULL once they are freed. However, the utilization of multiple or complex data structures may lower the usefulness of this strategy.

More Use After Free vulnerabilities (CWE-416)

Timeline

  1. CVE record published.
  2. CISA published its SSVC assessment (exploitation: none, automatable: no, technical impact: total).
  3. Record last changed materially (score, affected products, status or references).

References

Recent Use After Free vulnerabilities

Spotted an error? Tell us.