<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://db.gcve.eu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Wed, 30 Sep 2026 02:51:37 +0000</lastBuildDate>
    <item>
      <title>CVE-2022-48975 — gpiolib: fix memory leak in gpiochip_setup_dev()</title>
      <link>https://db.gcve.eu/vuln/cve-2022-48975</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;gpiolib: fix memory leak in gpiochip_setup_dev()&lt;/p&gt;
&lt;p&gt;Here is a backtrace report about memory leak detected in
gpiochip_setup_dev():&lt;/p&gt;
&lt;p&gt;unreferenced object 0xffff88810b406400 (size 512):
  comm &amp;#34;python3&amp;#34;, 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&lt;/p&gt;
&lt;p&gt;gcdev_register() &amp;amp; gcdev_unregister() would call device_add() &amp;amp;
device_del() (no matter CONFIG_GPIO_CDEV is enabled or not) to
register/unregister device.&lt;/p&gt;
&lt;p&gt;However, if device_add() succeeds, some resource (like
struct device_private allocated by device_private_init())
is not released by device_del().&lt;/p&gt;
&lt;p&gt;Therefore, after device_add() succeeds by gcdev_register(), it
needs to call put_device() to release resource in the error handle
path.&lt;/p&gt;
&lt;p&gt;Here we move forward the register of release function, and let it
release every piece of resource by put_device() instead of kfree().&lt;/p&gt;
&lt;p&gt;While at it, fix another subtle issue, i.e. when gc-&amp;gt;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&amp;#39;s not a bug per se,
but rather waste of the resources and potentially wrong expectation
about contents of the gdev-&amp;gt;descs variable.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;gpiolib: fix memory leak in gpiochip_setup_dev()&lt;/p&gt;
&lt;p&gt;Here is a backtrace report about memory leak detected in
gpiochip_setup_dev():&lt;/p&gt;
&lt;p&gt;unreferenced object 0xffff88810b406400 (size 512):
  comm &amp;#34;python3&amp;#34;, 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&lt;/p&gt;
&lt;p&gt;gcdev_register() &amp;amp; gcdev_unregister() would call device_add() &amp;amp;
device_del() (no matter CONFIG_GPIO_CDEV is enabled or not) to
register/unregister device.&lt;/p&gt;
&lt;p&gt;However, if device_add() succeeds, some resource (like
struct device_private allocated by device_private_init())
is not released by device_del().&lt;/p&gt;
&lt;p&gt;Therefore, after device_add() succeeds by gcdev_register(), it
needs to call put_device() to release resource in the error handle
path.&lt;/p&gt;
&lt;p&gt;Here we move forward the register of release function, and let it
release every piece of resource by put_device() instead of kfree().&lt;/p&gt;
&lt;p&gt;While at it, fix another subtle issue, i.e. when gc-&amp;gt;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&amp;#39;s not a bug per se,
but rather waste of the resources and potentially wrong expectation
about contents of the gdev-&amp;gt;descs variable.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/cve-2022-48975</guid>
    </item>
  </channel>
</rss>
