CVE-2026-72004 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: fix memory leak in ieee80211_register_hw()
If kmemdup() fails while copying supported band structures, the error path jumps to fail_rate. This skips rate_control_deinitialize() and leaks the initialized local->rate_ctrl.
Fix this by adding a fail_band label that shares the rate-control cleanup path before falling through to the remaining teardown.
The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc7.
An x86_64 allyesconfig build showed no new warnings. As we do not have a suitable mac80211 device/driver combination to test with, no runtime testing was able to be performed.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/02/2026
The Linux kernel vulnerability identified in the mac80211 subsystem represents a classic resource management error within the hardware registration process for wireless network interfaces. Specifically, this issue resides in the ieee80211_register_hw function, which is responsible for initializing and registering a new wireless device with the kernel's networking stack. During this initialization sequence, the system attempts to duplicate supported band structures using kmemdup. This memory allocation operation can fail under conditions of high system load or resource exhaustion. When such a failure occurs, the error handling logic incorrectly directs execution flow to an intermediate cleanup label labeled fail_rate rather than proceeding through the complete teardown procedure required for fully initialized components.
The technical flaw stems from an incomplete error path that neglects to invoke rate_control_deinitialize before returning control to the caller or attempting further initialization steps. Consequently, any memory allocated and structures initialized within the local->rate_ctrl object remain resident in kernel space without being properly released. This results in a persistent memory leak each time the wireless device registration fails due to allocation errors. Over time, particularly on systems with frequent interface up/down cycles or unstable network conditions that trigger repeated initialization attempts, these leaked allocations accumulate and consume available kernel memory resources.
From an operational perspective, this vulnerability poses a risk of gradual system degradation rather than immediate catastrophic failure. The primary impact is the depletion of kernel heap space, which can eventually lead to out-of-memory conditions affecting other critical subsystems within the operating environment. While the initial report notes that no new warnings were observed in specific build configurations and runtime testing was limited by hardware availability, the logical flaw remains present across multiple kernel versions including v7.1-rc7. The absence of immediate symptoms does not mitigate the long-term stability risks associated with unchecked memory consumption in a core networking component.
This vulnerability aligns with Common Weakness Enumeration category CWE-401, which describes missing release of memory after successful allocation. It also relates to improper resource cleanup practices often categorized under CWE-755 regarding failure to properly manage resources during error conditions. In the context of adversarial behavior modeling, while this is primarily a stability issue rather than an exploit vector for privilege escalation or remote code execution, persistent memory leaks can be leveraged in denial-of-service scenarios by inducing repeated allocation failures to accelerate resource exhaustion.
The resolution involves restructuring the error handling logic within ieee80211_register_hw to ensure that all initialized resources are properly released regardless of where initialization fails. By introducing a dedicated fail_band label that shares the rate-control cleanup path, the code guarantees that rate_control_deinitialize is called before proceeding to subsequent teardown steps. This correction ensures consistent resource lifecycle management and prevents the accumulation of orphaned memory structures in kernel space.
To mitigate this vulnerability, system administrators should ensure their Linux kernels are updated to versions containing the fix for this mac80211 patch. Monitoring tools that track kernel memory usage can help detect unusual growth patterns indicative of such leaks before they impact overall system performance. Additionally, developers integrating wireless drivers into custom builds should verify that error paths in hardware registration functions adhere strictly to complete cleanup protocols to prevent similar issues from arising during future development cycles.