<?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>Sun, 04 Oct 2026 01:53:21 +0000</lastBuildDate>
    <item>
      <title>CVE-2025-71194 — btrfs: fix deadlock in wait_current_trans() due to ignored transaction type</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2025-71194</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;btrfs: fix deadlock in wait_current_trans() due to ignored transaction type&lt;/p&gt;
&lt;p&gt;When wait_current_trans() is called during start_transaction(), it
currently waits for a blocked transaction without considering whether
the given transaction type actually needs to wait for that particular
transaction state. The btrfs_blocked_trans_types[] array already defines
which transaction types should wait for which transaction states, but
this check was missing in wait_current_trans().&lt;/p&gt;
&lt;p&gt;This can lead to a deadlock scenario involving two transactions and
pending ordered extents:&lt;/p&gt;
&lt;p&gt;1. Transaction A is in TRANS_STATE_COMMIT_DOING state&lt;/p&gt;
&lt;p&gt;2. A worker processing an ordered extent calls start_transaction()
     with TRANS_JOIN&lt;/p&gt;
&lt;p&gt;3. join_transaction() returns -EBUSY because Transaction A is in
     TRANS_STATE_COMMIT_DOING&lt;/p&gt;
&lt;p&gt;4. Transaction A moves to TRANS_STATE_UNBLOCKED and completes&lt;/p&gt;
&lt;p&gt;5. A new Transaction B is created (TRANS_STATE_RUNNING)&lt;/p&gt;
&lt;p&gt;6. The ordered extent from step 2 is added to Transaction B&amp;#39;s
     pending ordered extents&lt;/p&gt;
&lt;p&gt;7. Transaction B immediately starts commit by another task and
     enters TRANS_STATE_COMMIT_START&lt;/p&gt;
&lt;p&gt;8. The worker finally reaches wait_current_trans(), sees Transaction B
     in TRANS_STATE_COMMIT_START (a blocked state), and waits
     unconditionally&lt;/p&gt;
&lt;p&gt;9. However, TRANS_JOIN should NOT wait for TRANS_STATE_COMMIT_START
     according to btrfs_blocked_trans_types[]&lt;/p&gt;
&lt;p&gt;10. Transaction B…&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;btrfs: fix deadlock in wait_current_trans() due to ignored transaction type&lt;/p&gt;
&lt;p&gt;When wait_current_trans() is called during start_transaction(), it
currently waits for a blocked transaction without considering whether
the given transaction type actually needs to wait for that particular
transaction state. The btrfs_blocked_trans_types[] array already defines
which transaction types should wait for which transaction states, but
this check was missing in wait_current_trans().&lt;/p&gt;
&lt;p&gt;This can lead to a deadlock scenario involving two transactions and
pending ordered extents:&lt;/p&gt;
&lt;p&gt;1. Transaction A is in TRANS_STATE_COMMIT_DOING state&lt;/p&gt;
&lt;p&gt;2. A worker processing an ordered extent calls start_transaction()
     with TRANS_JOIN&lt;/p&gt;
&lt;p&gt;3. join_transaction() returns -EBUSY because Transaction A is in
     TRANS_STATE_COMMIT_DOING&lt;/p&gt;
&lt;p&gt;4. Transaction A moves to TRANS_STATE_UNBLOCKED and completes&lt;/p&gt;
&lt;p&gt;5. A new Transaction B is created (TRANS_STATE_RUNNING)&lt;/p&gt;
&lt;p&gt;6. The ordered extent from step 2 is added to Transaction B&amp;#39;s
     pending ordered extents&lt;/p&gt;
&lt;p&gt;7. Transaction B immediately starts commit by another task and
     enters TRANS_STATE_COMMIT_START&lt;/p&gt;
&lt;p&gt;8. The worker finally reaches wait_current_trans(), sees Transaction B
     in TRANS_STATE_COMMIT_START (a blocked state), and waits
     unconditionally&lt;/p&gt;
&lt;p&gt;9. However, TRANS_JOIN should NOT wait for TRANS_STATE_COMMIT_START
     according to btrfs_blocked_trans_types[]&lt;/p&gt;
&lt;p&gt;10. Transaction B…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2025-71194</guid>
    </item>
  </channel>
</rss>
