<?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, 06 Oct 2026 13:09:06 +0000</lastBuildDate>
    <item>
      <title>CVE-2024-39495 — greybus: Fix use-after-free bug in gb_interface_release due to race condition.</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2024-39495</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux, linux_kernel&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;greybus: Fix use-after-free bug in gb_interface_release due to race condition.&lt;/p&gt;
&lt;p&gt;In gb_interface_create, &amp;amp;intf-&amp;gt;mode_switch_completion is bound with
gb_interface_mode_switch_work. Then it will be started by
gb_interface_request_mode_switch. Here is the relevant code.
if (!queue_work(system_long_wq, &amp;amp;intf-&amp;gt;mode_switch_work)) {
	...
}&lt;/p&gt;
&lt;p&gt;If we call gb_interface_release to make cleanup, there may be an
unfinished work. This function will call kfree to free the object
&amp;#34;intf&amp;#34;. However, if gb_interface_mode_switch_work is scheduled to
run after kfree, it may cause use-after-free error as
gb_interface_mode_switch_work will use the object &amp;#34;intf&amp;#34;.
The possible execution flow that may lead to the issue is as follows:&lt;/p&gt;
&lt;p&gt;CPU0                            CPU1&lt;/p&gt;
&lt;p&gt;|   gb_interface_create
                            |   gb_interface_request_mode_switch
gb_interface_release        |
kfree(intf) (free)          |
                            |   gb_interface_mode_switch_work
                            |   mutex_lock(&amp;amp;intf-&amp;gt;mutex) (use)&lt;/p&gt;
&lt;p&gt;Fix it by canceling the work before kfree.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux, linux_kernel&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;greybus: Fix use-after-free bug in gb_interface_release due to race condition.&lt;/p&gt;
&lt;p&gt;In gb_interface_create, &amp;amp;intf-&amp;gt;mode_switch_completion is bound with
gb_interface_mode_switch_work. Then it will be started by
gb_interface_request_mode_switch. Here is the relevant code.
if (!queue_work(system_long_wq, &amp;amp;intf-&amp;gt;mode_switch_work)) {
	...
}&lt;/p&gt;
&lt;p&gt;If we call gb_interface_release to make cleanup, there may be an
unfinished work. This function will call kfree to free the object
&amp;#34;intf&amp;#34;. However, if gb_interface_mode_switch_work is scheduled to
run after kfree, it may cause use-after-free error as
gb_interface_mode_switch_work will use the object &amp;#34;intf&amp;#34;.
The possible execution flow that may lead to the issue is as follows:&lt;/p&gt;
&lt;p&gt;CPU0                            CPU1&lt;/p&gt;
&lt;p&gt;|   gb_interface_create
                            |   gb_interface_request_mode_switch
gb_interface_release        |
kfree(intf) (free)          |
                            |   gb_interface_mode_switch_work
                            |   mutex_lock(&amp;amp;intf-&amp;gt;mutex) (use)&lt;/p&gt;
&lt;p&gt;Fix it by canceling the work before kfree.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2024-39495</guid>
    </item>
  </channel>
</rss>
