Memory Leak Affecting kernel-default-base package, versions <5.14.21-150400.24.141.1.150400.24.68.2


Severity

Recommended
0.0
medium
0
10

Based on SUSE Linux Enterprise Server security rating.

Threat Intelligence

EPSS
0.04% (5th percentile)

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 Learn

Learn about Memory Leak vulnerabilities in an interactive lesson.

Start learning
  • Snyk IDSNYK-SLES154-KERNELDEFAULTBASE-8448166
  • published3 Dec 2024
  • disclosed2 Dec 2024

Introduced: 2 Dec 2024

NewCVE-2022-48975  (opens in a new tab)
CWE-401  (opens in a new tab)

How to fix?

Upgrade SLES:15.4 kernel-default-base to version 5.14.21-150400.24.141.1.150400.24.68.2 or higher.

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel-default-base package and not the kernel-default-base package as distributed by SLES. See How to fix? for SLES:15.4 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.

CVSS Scores

version 3.1