{"id":"CVE-2022-48975","summary":"gpiolib: fix memory leak in gpiochip_setup_dev()","details":"In the Linux kernel, the following vulnerability has been resolved:\n\ngpiolib: fix memory leak in gpiochip_setup_dev()\n\nHere is a backtrace report about memory leak detected in\ngpiochip_setup_dev():\n\nunreferenced object 0xffff88810b406400 (size 512):\n  comm \"python3\", pid 1682, jiffies 4295346908 (age 24.090s)\n  backtrace:\n    kmalloc_trace\n    device_add\t\tdevice_private_init at drivers/base/core.c:3361\n\t\t\t(inlined by) device_add at drivers/base/core.c:3411\n    cdev_device_add\n    gpiolib_cdev_register\n    gpiochip_setup_dev\n    gpiochip_add_data_with_key\n\ngcdev_register() & gcdev_unregister() would call device_add() &\ndevice_del() (no matter CONFIG_GPIO_CDEV is enabled or not) to\nregister/unregister device.\n\nHowever, if device_add() succeeds, some resource (like\nstruct device_private allocated by device_private_init())\nis not released by device_del().\n\nTherefore, after device_add() succeeds by gcdev_register(), it\nneeds to call put_device() to release resource in the error handle\npath.\n\nHere we move forward the register of release function, and let it\nrelease every piece of resource by put_device() instead of kfree().\n\nWhile at it, fix another subtle issue, i.e. when gc-\u003engpio is equal\nto 0, we still call kcalloc() and, in case of further error, kfree()\non the ZERO_PTR pointer, which is not NULL. It's not a bug per se,\nbut rather waste of the resources and potentially wrong expectation\nabout contents of the gdev-\u003edescs variable.","modified":"2026-04-02T08:27:11.939095Z","published":"2024-10-21T20:05:55.091Z","related":["SUSE-SU-2024:3983-1","SUSE-SU-2024:3985-1","SUSE-SU-2024:4082-1","SUSE-SU-2024:4131-1","SUSE-SU-2024:4364-1","SUSE-SU-2025:0834-1"],"database_specific":{"osv_generated_from":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2022/48xxx/CVE-2022-48975.json","cna_assigner":"Linux"},"references":[{"type":"WEB","url":"https://git.kernel.org/stable/c/371363716398ed718e389bea8c5e9843a79dde4e"},{"type":"WEB","url":"https://git.kernel.org/stable/c/6daaa84b621485fe28c401be18debf92ae8ef04a"},{"type":"WEB","url":"https://git.kernel.org/stable/c/ec851b23084b3a0af8bf0f5e51d33a8d678bdc49"},{"type":"ADVISORY","url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2022/48xxx/CVE-2022-48975.json"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48975"},{"type":"PACKAGE","url":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"}],"affected":[{"ranges":[{"type":"GIT","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","events":[{"introduced":"159f3cd92f17c61a4e2a47456de5865b114ef88e"},{"fixed":"6daaa84b621485fe28c401be18debf92ae8ef04a"},{"fixed":"371363716398ed718e389bea8c5e9843a79dde4e"},{"fixed":"ec851b23084b3a0af8bf0f5e51d33a8d678bdc49"}]}],"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2022-48975.json"}}],"schema_version":"1.7.5"}