CVE-2022-48975 in Linux
Summary
by MITRE • 10/21/2024
In the Linux kernel, the following vulnerability has been resolved:
gpiolib: fix memory leak in gpiochip_setup_dev()
Here is a backtrace report about memory leak detected in gpiochip_setup_dev():
unreferenced object 0xffff88810b406400 (size 512): comm "python3", pid 1682, jiffies 4295346908 (age 24.090s) backtrace: kmalloc_trace device_add device_private_init at drivers/base/core.c:3361 (inlined by) device_add at drivers/base/core.c:3411 cdev_device_add gpiolib_cdev_register gpiochip_setup_dev gpiochip_add_data_with_key
gcdev_register() & gcdev_unregister() would call device_add() & device_del() (no matter CONFIG_GPIO_CDEV is enabled or not) to register/unregister device.
However, if device_add() succeeds, some resource (like struct device_private allocated by device_private_init()) is not released by device_del().
Therefore, after device_add() succeeds by gcdev_register(), it needs to call put_device() to release resource in the error handle path.
Here we move forward the register of release function, and let it release every piece of resource by put_device() instead of kfree().
While at it, fix another subtle issue, i.e. when gc->ngpio is equal to 0, we still call kcalloc() and, in case of further error, kfree() on the ZERO_PTR pointer, which is not NULL. It's not a bug per se, but rather waste of the resources and potentially wrong expectation about contents of the gdev->descs variable.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 01/18/2026
The vulnerability CVE-2022-48975 addresses a memory leak in the Linux kernel's GPIO subsystem, specifically within the gpiolib component. This issue manifests in the gpiochip_setup_dev() function where improper resource management leads to unreferenced memory allocations that persist in the system. The problem occurs during the device registration process when GPIO chips are being set up, creating a scenario where memory allocated for device private structures is not properly released during error handling paths. The memory leak is particularly concerning as it can accumulate over time and potentially lead to system instability or resource exhaustion, especially in embedded systems or environments with frequent GPIO device operations. The vulnerability represents a classic case of improper resource cleanup in kernel space, where the expected lifecycle management of kernel objects fails to account for all possible error conditions.
The technical flaw stems from a mismatch in the device registration and cleanup mechanism within the GPIO subsystem. When gcdev_register() is called, it invokes device_add() which allocates memory for struct device_private structures through device_private_init(). However, if subsequent operations within gpiochip_setup_dev() fail, the cleanup path does not properly release these allocated resources. The standard device_del() function does not clean up all allocations made by device_add() in the error handling context, leaving memory fragments that are no longer referenced by any kernel objects. This creates a memory leak pattern where the kernel's memory management system fails to reclaim these unreferenced allocations. The issue is particularly subtle because it only manifests when device_add() succeeds but subsequent operations fail, making it difficult to detect during normal operation and potentially leading to gradual memory consumption over time.
The operational impact of this vulnerability extends beyond simple memory consumption, as it affects the overall stability and resource utilization of Linux systems that rely heavily on GPIO operations. Systems with frequent GPIO device creation and destruction cycles, such as embedded devices, IoT platforms, or servers managing numerous GPIO peripherals, are particularly susceptible to memory fragmentation and eventual resource depletion. The vulnerability affects both systems with and without CONFIG_GPIO_CDEV enabled, making it broadly applicable across different kernel configurations. When combined with other memory pressure conditions or long-running systems, this leak can contribute to performance degradation, system slowdowns, or even system crashes due to memory exhaustion. The memory leak pattern is consistent with CWE-401: Improper Release of Memory and aligns with ATT&CK technique T1490: Inhibit System Recovery, as it can lead to resource exhaustion that prevents normal system recovery operations.
The fix implemented addresses the core issue by repositioning the release function registration to ensure proper resource cleanup through put_device() calls rather than direct kfree() operations. This change ensures that when errors occur during GPIO chip setup, all allocated resources including device private structures are properly released back to the kernel's memory management system. Additionally, the patch addresses a secondary issue where kcalloc() was called even when ngpio equals zero, which would result in unnecessary memory allocation and subsequent kfree() operations on a zero pointer. The mitigation strategy follows established kernel memory management best practices by ensuring proper reference counting and resource lifecycle management. This fix demonstrates the importance of comprehensive error handling in kernel code, particularly in subsystems that manage hardware resources where improper cleanup can lead to systematic resource leaks. The resolution aligns with the principle of defensive programming in kernel space and addresses the fundamental issue of resource management consistency in the GPIO subsystem's device registration process.