CVE-2022-48975

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpiolib: fix memory leak in gpiochip_setup_dev()<br /> <br /> Here is a backtrace report about memory leak detected in<br /> gpiochip_setup_dev():<br /> <br /> unreferenced object 0xffff88810b406400 (size 512):<br /> comm "python3", pid 1682, jiffies 4295346908 (age 24.090s)<br /> backtrace:<br /> kmalloc_trace<br /> device_add device_private_init at drivers/base/core.c:3361<br /> (inlined by) device_add at drivers/base/core.c:3411<br /> cdev_device_add<br /> gpiolib_cdev_register<br /> gpiochip_setup_dev<br /> gpiochip_add_data_with_key<br /> <br /> gcdev_register() &amp; gcdev_unregister() would call device_add() &amp;<br /> device_del() (no matter CONFIG_GPIO_CDEV is enabled or not) to<br /> register/unregister device.<br /> <br /> However, if device_add() succeeds, some resource (like<br /> struct device_private allocated by device_private_init())<br /> is not released by device_del().<br /> <br /> Therefore, after device_add() succeeds by gcdev_register(), it<br /> needs to call put_device() to release resource in the error handle<br /> path.<br /> <br /> Here we move forward the register of release function, and let it<br /> release every piece of resource by put_device() instead of kfree().<br /> <br /> While at it, fix another subtle issue, i.e. when gc-&gt;ngpio is equal<br /> to 0, we still call kcalloc() and, in case of further error, kfree()<br /> on the ZERO_PTR pointer, which is not NULL. It&amp;#39;s not a bug per se,<br /> but rather waste of the resources and potentially wrong expectation<br /> about contents of the gdev-&gt;descs variable.