<?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>Thu, 01 Oct 2026 19:53:29 +0000</lastBuildDate>
    <item>
      <title>CVE-2025-37772 — RDMA/cma: Fix workqueue crash in cma_netevent_work_handler</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2025-37772</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;RDMA/cma: Fix workqueue crash in cma_netevent_work_handler&lt;/p&gt;
&lt;p&gt;struct rdma_cm_id has member &amp;#34;struct work_struct net_work&amp;#34;
that is reused for enqueuing cma_netevent_work_handler()s
onto cma_wq.&lt;/p&gt;
&lt;p&gt;Below crash[1] can occur if more than one call to
cma_netevent_callback() occurs in quick succession,
which further enqueues cma_netevent_work_handler()s for the
same rdma_cm_id, overwriting any previously queued work-item(s)
that was just scheduled to run i.e. there is no guarantee
the queued work item may run between two successive calls
to cma_netevent_callback() and the 2nd INIT_WORK would overwrite
the 1st work item (for the same rdma_cm_id), despite grabbing
id_table_lock during enqueue.&lt;/p&gt;
&lt;p&gt;Also drgn analysis [2] indicates the work item was likely overwritten.&lt;/p&gt;
&lt;p&gt;Fix this by moving the INIT_WORK() to __rdma_create_id(),
so that it doesn&amp;#39;t race with any existing queue_work() or
its worker thread.&lt;/p&gt;
&lt;p&gt;[1] Trimmed crash stack:
=============================================
BUG: kernel NULL pointer dereference, address: 0000000000000008
kworker/u256:6 ... 6.12.0-0...
Workqueue:  cma_netevent_work_handler [rdma_cm] (rdma_cm)
RIP: 0010:process_one_work+0xba/0x31a
Call Trace:
 worker_thread+0x266/0x3a0
 kthread+0xcf/0x100
 ret_from_fork+0x31/0x50
 ret_from_fork_asm+0x1a/0x30
=============================================&lt;/p&gt;
&lt;p&gt;[2] drgn crash analysis:&lt;/p&gt;
&lt;p&gt;&amp;gt;&amp;gt;&amp;gt; trace = prog.crashed_thread().stack_trace()
&amp;gt;&amp;gt;&amp;gt; trace
(0)  crash_setup_regs (./…&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;RDMA/cma: Fix workqueue crash in cma_netevent_work_handler&lt;/p&gt;
&lt;p&gt;struct rdma_cm_id has member &amp;#34;struct work_struct net_work&amp;#34;
that is reused for enqueuing cma_netevent_work_handler()s
onto cma_wq.&lt;/p&gt;
&lt;p&gt;Below crash[1] can occur if more than one call to
cma_netevent_callback() occurs in quick succession,
which further enqueues cma_netevent_work_handler()s for the
same rdma_cm_id, overwriting any previously queued work-item(s)
that was just scheduled to run i.e. there is no guarantee
the queued work item may run between two successive calls
to cma_netevent_callback() and the 2nd INIT_WORK would overwrite
the 1st work item (for the same rdma_cm_id), despite grabbing
id_table_lock during enqueue.&lt;/p&gt;
&lt;p&gt;Also drgn analysis [2] indicates the work item was likely overwritten.&lt;/p&gt;
&lt;p&gt;Fix this by moving the INIT_WORK() to __rdma_create_id(),
so that it doesn&amp;#39;t race with any existing queue_work() or
its worker thread.&lt;/p&gt;
&lt;p&gt;[1] Trimmed crash stack:
=============================================
BUG: kernel NULL pointer dereference, address: 0000000000000008
kworker/u256:6 ... 6.12.0-0...
Workqueue:  cma_netevent_work_handler [rdma_cm] (rdma_cm)
RIP: 0010:process_one_work+0xba/0x31a
Call Trace:
 worker_thread+0x266/0x3a0
 kthread+0xcf/0x100
 ret_from_fork+0x31/0x50
 ret_from_fork_asm+0x1a/0x30
=============================================&lt;/p&gt;
&lt;p&gt;[2] drgn crash analysis:&lt;/p&gt;
&lt;p&gt;&amp;gt;&amp;gt;&amp;gt; trace = prog.crashed_thread().stack_trace()
&amp;gt;&amp;gt;&amp;gt; trace
(0)  crash_setup_regs (./…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2025-37772</guid>
    </item>
  </channel>
</rss>
