<?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://vulnerability.circl.lu</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>Tue, 29 Sep 2026 16:26:42 +0000</lastBuildDate>
    <item>
      <title>CVE-2025-39937 — net: rfkill: gpio: Fix crash due to dereferencering uninitialized pointer</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2025-39937</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;net: rfkill: gpio: Fix crash due to dereferencering uninitialized pointer&lt;/p&gt;
&lt;p&gt;Since commit 7d5e9737efda (&amp;#34;net: rfkill: gpio: get the name and type from
device property&amp;#34;) rfkill_find_type() gets called with the possibly
uninitialized &amp;#34;const char *type_name;&amp;#34; local variable.&lt;/p&gt;
&lt;p&gt;On x86 systems when rfkill-gpio binds to a &amp;#34;BCM4752&amp;#34; or &amp;#34;LNV4752&amp;#34;
acpi_device, the rfkill-&amp;gt;type is set based on the ACPI acpi_device_id:&lt;/p&gt;
&lt;p&gt;rfkill-&amp;gt;type = (unsigned)id-&amp;gt;driver_data;&lt;/p&gt;
&lt;p&gt;and there is no &amp;#34;type&amp;#34; property so device_property_read_string() will fail
and leave type_name uninitialized, leading to a potential crash.&lt;/p&gt;
&lt;p&gt;rfkill_find_type() does accept a NULL pointer, fix the potential crash
by initializing type_name to NULL.&lt;/p&gt;
&lt;p&gt;Note likely sofar this has not been caught because:&lt;/p&gt;
&lt;p&gt;1. Not many x86 machines actually have a &amp;#34;BCM4752&amp;#34;/&amp;#34;LNV4752&amp;#34; acpi_device
2. The stack happened to contain NULL where type_name is stored&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;net: rfkill: gpio: Fix crash due to dereferencering uninitialized pointer&lt;/p&gt;
&lt;p&gt;Since commit 7d5e9737efda (&amp;#34;net: rfkill: gpio: get the name and type from
device property&amp;#34;) rfkill_find_type() gets called with the possibly
uninitialized &amp;#34;const char *type_name;&amp;#34; local variable.&lt;/p&gt;
&lt;p&gt;On x86 systems when rfkill-gpio binds to a &amp;#34;BCM4752&amp;#34; or &amp;#34;LNV4752&amp;#34;
acpi_device, the rfkill-&amp;gt;type is set based on the ACPI acpi_device_id:&lt;/p&gt;
&lt;p&gt;rfkill-&amp;gt;type = (unsigned)id-&amp;gt;driver_data;&lt;/p&gt;
&lt;p&gt;and there is no &amp;#34;type&amp;#34; property so device_property_read_string() will fail
and leave type_name uninitialized, leading to a potential crash.&lt;/p&gt;
&lt;p&gt;rfkill_find_type() does accept a NULL pointer, fix the potential crash
by initializing type_name to NULL.&lt;/p&gt;
&lt;p&gt;Note likely sofar this has not been caught because:&lt;/p&gt;
&lt;p&gt;1. Not many x86 machines actually have a &amp;#34;BCM4752&amp;#34;/&amp;#34;LNV4752&amp;#34; acpi_device
2. The stack happened to contain NULL where type_name is stored&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2025-39937</guid>
    </item>
  </channel>
</rss>
