Memory Leak Affecting kernel-livepatch-5_14_21-150500_55_88-default package, versions <1-150500.11.5.1
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-SLES155-KERNELLIVEPATCH514211505005588DEFAULT-8519764
- published18 Dec 2024
- disclosed17 Dec 2024
Introduced: 17 Dec 2024
NewCVE-2022-48975 (opens in a new tab)How to fix?
Upgrade SLES:15.5 kernel-livepatch-5_14_21-150500_55_88-default to version 1-150500.11.5.1 or higher.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-livepatch-5_14_21-150500_55_88-default package and not the kernel-livepatch-5_14_21-150500_55_88-default package as distributed by SLES.
See How to fix? for SLES:15.5 relevant fixed versions and status.
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.
References
- https://www.suse.com/security/cve/CVE-2022-48975.html
- https://bugzilla.suse.com/1231885
- https://git.kernel.org/stable/c/371363716398ed718e389bea8c5e9843a79dde4e
- https://git.kernel.org/stable/c/6daaa84b621485fe28c401be18debf92ae8ef04a
- https://git.kernel.org/stable/c/ec851b23084b3a0af8bf0f5e51d33a8d678bdc49