<?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>Mon, 05 Oct 2026 10:19:15 +0000</lastBuildDate>
    <item>
      <title>CVE-2025-38628 — vdpa/mlx5: Fix release of uninitialized resources on error path</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2025-38628</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;vdpa/mlx5: Fix release of uninitialized resources on error path&lt;/p&gt;
&lt;p&gt;The commit in the fixes tag made sure that mlx5_vdpa_free()
is the single entrypoint for removing the vdpa device resources
added in mlx5_vdpa_dev_add(), even in the cleanup path of
mlx5_vdpa_dev_add().&lt;/p&gt;
&lt;p&gt;This means that all functions from mlx5_vdpa_free() should be able to
handle uninitialized resources. This was not the case though:
mlx5_vdpa_destroy_mr_resources() and mlx5_cmd_cleanup_async_ctx()
were not able to do so. This caused the splat below when adding
a vdpa device without a MAC address.&lt;/p&gt;
&lt;p&gt;This patch fixes these remaining issues:&lt;/p&gt;
&lt;p&gt;- Makes mlx5_vdpa_destroy_mr_resources() return early if called on
  uninitialized resources.&lt;/p&gt;
&lt;p&gt;- Moves mlx5_cmd_init_async_ctx() early on during device addition
  because it can&amp;#39;t fail. This means that mlx5_cmd_cleanup_async_ctx()
  also can&amp;#39;t fail. To mirror this, move the call site of
  mlx5_cmd_cleanup_async_ctx() in mlx5_vdpa_free().&lt;/p&gt;
&lt;p&gt;An additional comment was added in mlx5_vdpa_free() to document
the expectations of functions called from this context.&lt;/p&gt;
&lt;p&gt;Splat:&lt;/p&gt;
&lt;p&gt;mlx5_core 0000:b5:03.2: mlx5_vdpa_dev_add:3950:(pid 2306) warning: No mac address provisioned?
  ------------[ cut here ]------------
  WARNING: CPU: 13 PID: 2306 at kernel/workqueue.c:4207 __flush_work+0x9a/0xb0
  [...]
  Call Trace:
   &amp;lt;TASK&amp;gt;
   ? __try_to_del_timer_sync+0x61/0x90
   ? __timer_delete_sync+0x2b/0x40
   mlx5_vdpa_destroy_mr_reso…&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;vdpa/mlx5: Fix release of uninitialized resources on error path&lt;/p&gt;
&lt;p&gt;The commit in the fixes tag made sure that mlx5_vdpa_free()
is the single entrypoint for removing the vdpa device resources
added in mlx5_vdpa_dev_add(), even in the cleanup path of
mlx5_vdpa_dev_add().&lt;/p&gt;
&lt;p&gt;This means that all functions from mlx5_vdpa_free() should be able to
handle uninitialized resources. This was not the case though:
mlx5_vdpa_destroy_mr_resources() and mlx5_cmd_cleanup_async_ctx()
were not able to do so. This caused the splat below when adding
a vdpa device without a MAC address.&lt;/p&gt;
&lt;p&gt;This patch fixes these remaining issues:&lt;/p&gt;
&lt;p&gt;- Makes mlx5_vdpa_destroy_mr_resources() return early if called on
  uninitialized resources.&lt;/p&gt;
&lt;p&gt;- Moves mlx5_cmd_init_async_ctx() early on during device addition
  because it can&amp;#39;t fail. This means that mlx5_cmd_cleanup_async_ctx()
  also can&amp;#39;t fail. To mirror this, move the call site of
  mlx5_cmd_cleanup_async_ctx() in mlx5_vdpa_free().&lt;/p&gt;
&lt;p&gt;An additional comment was added in mlx5_vdpa_free() to document
the expectations of functions called from this context.&lt;/p&gt;
&lt;p&gt;Splat:&lt;/p&gt;
&lt;p&gt;mlx5_core 0000:b5:03.2: mlx5_vdpa_dev_add:3950:(pid 2306) warning: No mac address provisioned?
  ------------[ cut here ]------------
  WARNING: CPU: 13 PID: 2306 at kernel/workqueue.c:4207 __flush_work+0x9a/0xb0
  [...]
  Call Trace:
   &amp;lt;TASK&amp;gt;
   ? __try_to_del_timer_sync+0x61/0x90
   ? __timer_delete_sync+0x2b/0x40
   mlx5_vdpa_destroy_mr_reso…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2025-38628</guid>
    </item>
  </channel>
</rss>
