CVE-2022-48975

  1. Yack CVE
  2. Vulnerabilities (CVE)
  3. CVE-2022-48975

5.5 /10

CVSS v3 : MEDIUM

V3 Legend

Vector :

Exploitability : 1.8 / Impact : 3.6

Attack Vector LOCAL

Attack Complexity LOW

Privileges Required LOW

User Interaction NONE

Confidentiality Impact NONE

Integrity Impact NONE

Availability Impact HIGH

Scope UNCHANGED

I

n 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
Link Resource
https://git.kernel.org/stable/c/371363716398ed718e389bea8c5e9843a79dde4e Patch
https://git.kernel.org/stable/c/6daaa84b621485fe28c401be18debf92ae8ef04a Patch
https://git.kernel.org/stable/c/ec851b23084b3a0af8bf0f5e51d33a8d678bdc49 Patch
Configurations

Configuration 1 (hide)

OR cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.1:rc1:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.1:rc2:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.1:rc3:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.1:rc4:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.1:rc5:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.1:rc6:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.1:rc7:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.1:rc8:*:*:*:*:*:*
History

25 Oct 2024, 18:48

Type Values Removed Values Added
CPE cpe:2.3:o:linux:linux_kernel:6.1:rc3:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.1:rc6:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.1:rc4:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.1:rc2:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.1:rc5:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.1:rc8:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.1:rc7:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.1:rc1:*:*:*:*:*:*
CVSS v2 : unknown
v3 : unknown 		v2 : unknown
v3 : 5.5
CWE CWE-401
First Time Linux
Linux linux Kernel
References () https://git.kernel.org/stable/c/371363716398ed718e389bea8c5e9843a79dde4e - () https://git.kernel.org/stable/c/371363716398ed718e389bea8c5e9843a79dde4e - Patch
References () https://git.kernel.org/stable/c/6daaa84b621485fe28c401be18debf92ae8ef04a - () https://git.kernel.org/stable/c/6daaa84b621485fe28c401be18debf92ae8ef04a - Patch
References () https://git.kernel.org/stable/c/ec851b23084b3a0af8bf0f5e51d33a8d678bdc49 - () https://git.kernel.org/stable/c/ec851b23084b3a0af8bf0f5e51d33a8d678bdc49 - Patch

23 Oct 2024, 15:13

Type Values Removed Values Added
Summary
  • (es) En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gpiolib: reparar pérdida de memoria en gpiochip_setup_dev() Aquí hay un informe de seguimiento sobre la pérdida de memoria detectada en gpiochip_setup_dev(): objeto sin referencia 0xffff88810b406400 (tamaño 512): comm "python3", pid 1682, jiffies 4295346908 (edad 24.090s) seguimiento: kmalloc_trace device_add device_private_init en drivers/base/core.c:3361 (en línea por) device_add en drivers/base/core.c:3411 cdev_device_add gpiolib_cdev_register gpiochip_setup_dev gpiochip_add_data_with_key gcdev_register() y gcdev_unregister() llamarían device_add() y device_del() (sin importar si CONFIG_GPIO_CDEV está habilitado o no) para registrar/anular el registro del dispositivo. Sin embargo, si device_add() tiene éxito, algún recurso (como la estructura device_private asignada por device_private_init()) no es liberado por device_del(). Por lo tanto, después de que device_add() tenga éxito por gcdev_register(), necesita llamar a put_device() para liberar el recurso en la ruta del controlador de error. Aquí avanzamos el registro de la función de liberación y dejamos que libere cada pieza de recurso por put_device() en lugar de kfree(). Mientras lo hacemos, solucionamos otro problema sutil, es decir, cuando gc->ngpio es igual a 0, todavía llamamos a kcalloc() y, en caso de un error adicional, a kfree() en el puntero ZERO_PTR, que no es NULL. No es un error en sí, sino más bien un desperdicio de recursos y una expectativa potencialmente errónea sobre el contenido de la variable gdev->descs.

21 Oct 2024, 20:15

Type Values Removed Values Added
New CVE
Information

Published : 2024-10-21 20:15

Updated : 2024-10-25 18:48

NVD link : CVE-2022-48975

Mitre link : CVE-2022-48975

CVE.ORG link : CVE-2022-48975

JSON object : View

Products Affected

linux

CWE
CWE-401

Missing Release of Memory after Effective Lifetime