CVE-2022-48975: gpiolib: fix memory leak in gpiochip_setup_dev()
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.
Security readout for executives and security teams
Plain-English summary
This CVE is a Linux kernel memory leak in GPIO device setup error handling. If the affected path is triggered repeatedly, kernel memory could be wasted and may affect availability. The source bundle does not show data theft, privilege escalation, remote exploitation, CVSS scoring, or active exploitation.
Executive priority
Treat this as routine kernel maintenance unless the organization operates GPIO-heavy or embedded Linux fleets. There is no source-backed evidence of active exploitation, but availability-sensitive systems should receive timely vendor kernel updates.
Technical view
In gpiolib, gpiochip_setup_dev() could call device_add() successfully and then miss put_device() on later error paths, leaking device_private resources. The fix moves release handling earlier and avoids unnecessary zero-length descriptor allocation behavior when gc->ngpio is zero.
Likely exposure
Exposure is most likely on Linux systems running affected kernel versions or unpatched vendor backports that use GPIO/gpiolib device registration paths. Internet-facing exposure is not indicated by the provided sources.
Exploitation context
CISA KEV status is false, and the provided sources do not claim active exploitation. The bundle describes a memory leak observed by backtrace, but does not establish practical exploitability, required privileges, or repeatability conditions.
Researcher notes
The record lacks CVSS, CWE, and exploitability detail. Analysis should stay focused on the documented gpiolib error-path leak and the referenced stable commits. Do not infer remote attack surface or privilege impact from the provided evidence.
Mitigation direction
Update to a vendor kernel containing the referenced stable fixes or equivalent backport.
Prioritize embedded, hardware-control, and GPIO-heavy Linux systems for review.
Check Linux distribution advisories before assuming upstream version numbers map directly.
Use normal change control and reboot planning for kernel updates.
Validation and detection
Inventory Linux kernel versions and vendor patch levels across affected systems.
Confirm whether vendor kernels include the referenced upstream stable commits or backports.
Review kernel release notes for the gpiolib memory leak fix.
Monitor affected systems for kernel memory pressure if patching is delayed.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2022-48975 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.