CVE-2026-99190 in Linux
Summary
by MITRE • 10/28/2026
In the Linux kernel, the following vulnerability has been resolved:
gpiolib: fix memory leak in gpiod_set_array_value_complex() on error paths
A drive-by review by Sashiko reports that, after a failed call to gpiochip_set_multiple(), gpiod_set_array_value() returns abruptly, bypassing the freeing of possibly alloced bitmaps, potentially leaking memory. It is an unlikely error path, but is possible.
Defer the return code check until after the bitmap_free() block.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/28/2026
The Linux kernel's general-purpose input/output subsystem contains a resource management flaw within the gpiod_set_array_value_complex function that results in a memory leak under specific failure conditions. This vulnerability arises from an improper handling of error paths during the execution of GPIO chip operations, specifically when interacting with the gpiochip_set_multiple interface. The core issue lies in the control flow logic which prematurely exits the function upon encountering an error code returned by the underlying hardware abstraction layer without first releasing dynamically allocated resources.
The technical root cause is identified as a missing cleanup sequence for bitmap data structures that were previously allocated to manage GPIO state arrays. When gpiod_set_array_value_complex invokes gpiochip_set_multiple, it expects either successful completion or a standard error return value. However, the existing implementation checks this return status immediately and returns early if an error is detected. This abrupt termination bypasses the subsequent bitmap_free calls that are necessary to deallocate memory buffers reserved for tracking GPIO states. Consequently, any memory allocated prior to the failed operation remains resident in kernel space indefinitely until system reboot or module unload, leading to a gradual depletion of available kernel memory over time.
This type of vulnerability is classified under CWE-401, which describes missing release of memory after effective usage. In the context of modern security frameworks such as MITRE ATT&CK, this flaw aligns with techniques related to resource exhaustion and potential denial-of-service scenarios through gradual system degradation. While the specific error path triggering this leak may be rare in typical operational environments, its existence represents a significant reliability concern for long-running systems or those subjected to high-frequency GPIO operations where transient hardware errors might occur frequently.
The impact of this vulnerability is primarily characterized by incremental memory consumption within the kernel address space. Although individual leaks are small due to the nature of bitmap allocations, repeated occurrences can contribute to overall system instability over extended periods. In worst-case scenarios involving automated systems or embedded devices with limited resources, such leaks could eventually lead to out-of-memory conditions affecting critical services or causing system crashes. The lack of immediate catastrophic failure does not diminish the severity as it undermines long-term system integrity and predictability.
To mitigate this vulnerability, developers must ensure that all allocated resources are freed before any early return statements within functions managing dynamic memory. The resolution involves restructuring the control flow to defer error code checks until after the cleanup block has executed. This ensures that bitmap_free is called regardless of whether subsequent operations succeed or fail. Maintaining strict adherence to resource acquisition and release ordering principles prevents such leaks and enhances the robustness of kernel subsystems against transient hardware faults.
Administrators should monitor system memory usage patterns for anomalies indicative of kernel-level leaks, particularly in environments with heavy GPIO activity. Applying vendor-provided patches that incorporate this fix is essential for maintaining security posture. Furthermore, code review processes within development teams should emphasize verification of cleanup paths on all error branches to prevent similar issues from being introduced into other parts of the operating system.