<?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://cve.radiocsirt.org</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 23:48:44 +0000</lastBuildDate>
    <item>
      <title>CVE-2022-48833 — btrfs: skip reserved bytes warning on unmount after log cleanup failure</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2022-48833</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: skip reserved bytes warning on unmount after log cleanup failure&lt;/p&gt;
&lt;p&gt;After the recent changes made by commit c2e39305299f01 (&amp;#34;btrfs: clear
extent buffer uptodate when we fail to write it&amp;#34;) and its followup fix,
commit 651740a5024117 (&amp;#34;btrfs: check WRITE_ERR when trying to read an
extent buffer&amp;#34;), we can now end up not cleaning up space reservations of
log tree extent buffers after a transaction abort happens, as well as not
cleaning up still dirty extent buffers.&lt;/p&gt;
&lt;p&gt;This happens because if writeback for a log tree extent buffer failed,
then we have cleared the bit EXTENT_BUFFER_UPTODATE from the extent buffer
and we have also set the bit EXTENT_BUFFER_WRITE_ERR on it. Later on,
when trying to free the log tree with free_log_tree(), which iterates
over the tree, we can end up getting an -EIO error when trying to read
a node or a leaf, since read_extent_buffer_pages() returns -EIO if an
extent buffer does not have EXTENT_BUFFER_UPTODATE set and has the
EXTENT_BUFFER_WRITE_ERR bit set. Getting that -EIO means that we return
immediately as we can not iterate over the entire tree.&lt;/p&gt;
&lt;p&gt;In that case we never update the reserved space for an extent buffer in
the respective block group and space_info object.&lt;/p&gt;
&lt;p&gt;When this happens we get the following traces when unmounting the fs:&lt;/p&gt;
&lt;p&gt;[174957.284509] BTRFS: error (device dm-0) in cleanup_transaction:1913: errno=-5 IO failure
[174957.286497] BTRFS: error (device dm-0) in fr…&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: skip reserved bytes warning on unmount after log cleanup failure&lt;/p&gt;
&lt;p&gt;After the recent changes made by commit c2e39305299f01 (&amp;#34;btrfs: clear
extent buffer uptodate when we fail to write it&amp;#34;) and its followup fix,
commit 651740a5024117 (&amp;#34;btrfs: check WRITE_ERR when trying to read an
extent buffer&amp;#34;), we can now end up not cleaning up space reservations of
log tree extent buffers after a transaction abort happens, as well as not
cleaning up still dirty extent buffers.&lt;/p&gt;
&lt;p&gt;This happens because if writeback for a log tree extent buffer failed,
then we have cleared the bit EXTENT_BUFFER_UPTODATE from the extent buffer
and we have also set the bit EXTENT_BUFFER_WRITE_ERR on it. Later on,
when trying to free the log tree with free_log_tree(), which iterates
over the tree, we can end up getting an -EIO error when trying to read
a node or a leaf, since read_extent_buffer_pages() returns -EIO if an
extent buffer does not have EXTENT_BUFFER_UPTODATE set and has the
EXTENT_BUFFER_WRITE_ERR bit set. Getting that -EIO means that we return
immediately as we can not iterate over the entire tree.&lt;/p&gt;
&lt;p&gt;In that case we never update the reserved space for an extent buffer in
the respective block group and space_info object.&lt;/p&gt;
&lt;p&gt;When this happens we get the following traces when unmounting the fs:&lt;/p&gt;
&lt;p&gt;[174957.284509] BTRFS: error (device dm-0) in cleanup_transaction:1913: errno=-5 IO failure
[174957.286497] BTRFS: error (device dm-0) in fr…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cve-2022-48833</guid>
    </item>
  </channel>
</rss>
