<?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 07:18:52 +0000</lastBuildDate>
    <item>
      <title>CVE-2024-42077 — ocfs2: fix DIO failure due to insufficient transaction credits</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2024-42077</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;ocfs2: fix DIO failure due to insufficient transaction credits&lt;/p&gt;
&lt;p&gt;The code in ocfs2_dio_end_io_write() estimates number of necessary
transaction credits using ocfs2_calc_extend_credits().  This however does
not take into account that the IO could be arbitrarily large and can
contain arbitrary number of extents.&lt;/p&gt;
&lt;p&gt;Extent tree manipulations do often extend the current transaction but not
in all of the cases.  For example if we have only single block extents in
the tree, ocfs2_mark_extent_written() will end up calling
ocfs2_replace_extent_rec() all the time and we will never extend the
current transaction and eventually exhaust all the transaction credits if
the IO contains many single block extents.  Once that happens a
WARN_ON(jbd2_handle_buffer_credits(handle) &amp;lt;= 0) is triggered in
jbd2_journal_dirty_metadata() and subsequently OCFS2 aborts in response to
this error.  This was actually triggered by one of our customers on a
heavily fragmented OCFS2 filesystem.&lt;/p&gt;
&lt;p&gt;To fix the issue make sure the transaction always has enough credits for
one extent insert before each call of ocfs2_mark_extent_written().&lt;/p&gt;
&lt;p&gt;Heming Zhao said:&lt;/p&gt;
&lt;p&gt;------
PANIC: &amp;#34;Kernel panic - not syncing: OCFS2: (device dm-1): panic forced after error&amp;#34;&lt;/p&gt;
&lt;p&gt;PID: xxx  TASK: xxxx  CPU: 5  COMMAND: &amp;#34;SubmitThread-CA&amp;#34;
  #0 machine_kexec at ffffffff8c069932
  #1 __crash_kexec at ffffffff8c1338fa
  #2 panic at ffffffff8c1d69b9
  #3 ocfs2_handle_error at ffffffffc0c8…&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;ocfs2: fix DIO failure due to insufficient transaction credits&lt;/p&gt;
&lt;p&gt;The code in ocfs2_dio_end_io_write() estimates number of necessary
transaction credits using ocfs2_calc_extend_credits().  This however does
not take into account that the IO could be arbitrarily large and can
contain arbitrary number of extents.&lt;/p&gt;
&lt;p&gt;Extent tree manipulations do often extend the current transaction but not
in all of the cases.  For example if we have only single block extents in
the tree, ocfs2_mark_extent_written() will end up calling
ocfs2_replace_extent_rec() all the time and we will never extend the
current transaction and eventually exhaust all the transaction credits if
the IO contains many single block extents.  Once that happens a
WARN_ON(jbd2_handle_buffer_credits(handle) &amp;lt;= 0) is triggered in
jbd2_journal_dirty_metadata() and subsequently OCFS2 aborts in response to
this error.  This was actually triggered by one of our customers on a
heavily fragmented OCFS2 filesystem.&lt;/p&gt;
&lt;p&gt;To fix the issue make sure the transaction always has enough credits for
one extent insert before each call of ocfs2_mark_extent_written().&lt;/p&gt;
&lt;p&gt;Heming Zhao said:&lt;/p&gt;
&lt;p&gt;------
PANIC: &amp;#34;Kernel panic - not syncing: OCFS2: (device dm-1): panic forced after error&amp;#34;&lt;/p&gt;
&lt;p&gt;PID: xxx  TASK: xxxx  CPU: 5  COMMAND: &amp;#34;SubmitThread-CA&amp;#34;
  #0 machine_kexec at ffffffff8c069932
  #1 __crash_kexec at ffffffff8c1338fa
  #2 panic at ffffffff8c1d69b9
  #3 ocfs2_handle_error at ffffffffc0c8…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2024-42077</guid>
    </item>
  </channel>
</rss>
