CVE-2026-99023 in Linux
Summary
by MITRE • 10/23/2026
In the Linux kernel, the following vulnerability has been resolved:
power: sequencing: pcie-m2: Fix leaking array from of_regulator_bulk_get_all()
of_regulator_bulk_get_all() allocates the consumers array and hands it to the caller, who is expected to free it at an appropriate time. pwrseq-pcie-m2.c never did, leading to a memory leak.
Add an explicit kfree() for the consumers array.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/23/2026
The Linux kernel power sequencing subsystem contains a specific implementation flaw within the PCIe M.2 power sequence driver that results in a persistent memory leak. This vulnerability stems from improper resource management during the initialization phase of the hardware interface, specifically when interacting with regulator supplies required for proper device operation. The function of_regulator_bulk_get_all() is designed to allocate an array of consumer structures representing various regulators associated with a PCIe M.2 slot and returns this dynamically allocated memory to the caller. Standard kernel programming conventions dictate that any entity receiving such dynamically allocated resources assumes responsibility for their eventual deallocation to prevent system resource exhaustion over time.
In the specific case of the pwrseq-pcie-m2 driver, the code fails to invoke kfree() on the consumers array after it has been utilized or when the device is being removed from the system bus. This omission means that every instance where this driver initializes and subsequently tears down a PCIe M.2 power sequence context leaves behind an unfreed block of kernel memory. While individual leaks may appear negligible in terms of immediate impact, they accumulate with each hotplug event or module reload cycle. Over extended periods of operation, particularly on systems frequently utilizing removable storage devices via PCIe M.2 interfaces, this unbounded allocation can contribute to gradual degradation of available system memory and potentially lead to out-of-memory conditions under heavy load scenarios involving frequent device attachment and detachment operations.
From a classification perspective, this vulnerability aligns with CWE-401, which describes the failure to release allocated memory after it is no longer needed. This type of error represents a classic resource management oversight where the lifecycle of dynamically allocated data structures is not properly synchronized with the lifecycle of the owning component. In terms of adversarial behavior mapping, while this specific flaw does not directly facilitate privilege escalation or remote code execution in its current state, memory leaks are often precursors to more severe stability issues and can be leveraged in denial-of-service attacks if an attacker can trigger repeated initialization cycles rapidly enough to exhaust kernel memory pools. The ATT&CK framework categorizes such resource exhaustion techniques under the broader umbrella of impact tactics where system availability is compromised through resource depletion rather than direct exploitation of logic flaws for access control bypasses.
The operational impact of this vulnerability primarily centers on system stability and long-term reliability rather than immediate security compromise. Administrators may observe increasing memory usage in kernel space over time, which could eventually trigger the Linux Out-Of-Memory killer to terminate critical processes if total available memory becomes critically low. Furthermore, such leaks indicate a lack of robustness in error handling paths; often, when one allocation path is missed during normal operation, other failure modes or early exits might also suffer from similar resource leakage issues within the same driver module. This suggests that while the primary fix addresses the specific leak identified by static analysis tools like Kmemleak, it serves as a critical patch for maintaining the integrity of the kernel's memory management subsystem in high-churn environments.
To mitigate this vulnerability and prevent future occurrences, developers must ensure strict adherence to resource acquisition is initialization (RAII) principles or explicit cleanup protocols within Linux kernel drivers. The immediate remediation involves adding an explicit kfree() call for the consumers array at all exit points where the driver releases its hold on regulator resources, including both normal removal paths and error handling branches during probe operations. Beyond this specific fix, a broader audit of similar patterns in other power sequencing drivers is recommended to identify any analogous leaks involving bulk regulator or clock acquisitions. Implementing automated static analysis tools that track memory allocation and deallocation pairs can help detect such discrepancies early in the development cycle before they reach production kernels. Additionally, rigorous testing procedures should include stress tests involving rapid device hotplugging to verify that no residual memory artifacts remain after each operation completes successfully.