<?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, 28 Sep 2026 19:36:39 +0000</lastBuildDate>
    <item>
      <title>CVE-2022-49769 — gfs2: Check sb_bsize_shift after reading superblock</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2022-49769</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;gfs2: Check sb_bsize_shift after reading superblock&lt;/p&gt;
&lt;p&gt;Fuzzers like to scribble over sb_bsize_shift but in reality it&amp;#39;s very
unlikely that this field would be corrupted on its own. Nevertheless it
should be checked to avoid the possibility of messy mount errors due to
bad calculations. It&amp;#39;s always a fixed value based on the block size so
we can just check that it&amp;#39;s the expected value.&lt;/p&gt;
&lt;p&gt;Tested with:&lt;/p&gt;
&lt;p&gt;mkfs.gfs2 -O -p lock_nolock /dev/vdb
    for i in 0 -1 64 65 32 33; do
        gfs2_edit -p sb field sb_bsize_shift $i /dev/vdb
        mount /dev/vdb /mnt/test &amp;amp;&amp;amp; umount /mnt/test
    done&lt;/p&gt;
&lt;p&gt;Before this patch we get a withdraw after&lt;/p&gt;
&lt;p&gt;[   76.413681] gfs2: fsid=loop0.0: fatal: invalid metadata block
[   76.413681]   bh = 19 (type: exp=5, found=4)
[   76.413681]   function = gfs2_meta_buffer, file = fs/gfs2/meta_io.c, line = 492&lt;/p&gt;
&lt;p&gt;and with UBSAN configured we also get complaints like&lt;/p&gt;
&lt;p&gt;[   76.373395] UBSAN: shift-out-of-bounds in fs/gfs2/ops_fstype.c:295:19
[   76.373815] shift exponent 4294967287 is too large for 64-bit type &amp;#39;long unsigned int&amp;#39;&lt;/p&gt;
&lt;p&gt;After the patch, these complaints don&amp;#39;t appear, mount fails immediately
and we get an explanation in dmesg.&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;gfs2: Check sb_bsize_shift after reading superblock&lt;/p&gt;
&lt;p&gt;Fuzzers like to scribble over sb_bsize_shift but in reality it&amp;#39;s very
unlikely that this field would be corrupted on its own. Nevertheless it
should be checked to avoid the possibility of messy mount errors due to
bad calculations. It&amp;#39;s always a fixed value based on the block size so
we can just check that it&amp;#39;s the expected value.&lt;/p&gt;
&lt;p&gt;Tested with:&lt;/p&gt;
&lt;p&gt;mkfs.gfs2 -O -p lock_nolock /dev/vdb
    for i in 0 -1 64 65 32 33; do
        gfs2_edit -p sb field sb_bsize_shift $i /dev/vdb
        mount /dev/vdb /mnt/test &amp;amp;&amp;amp; umount /mnt/test
    done&lt;/p&gt;
&lt;p&gt;Before this patch we get a withdraw after&lt;/p&gt;
&lt;p&gt;[   76.413681] gfs2: fsid=loop0.0: fatal: invalid metadata block
[   76.413681]   bh = 19 (type: exp=5, found=4)
[   76.413681]   function = gfs2_meta_buffer, file = fs/gfs2/meta_io.c, line = 492&lt;/p&gt;
&lt;p&gt;and with UBSAN configured we also get complaints like&lt;/p&gt;
&lt;p&gt;[   76.373395] UBSAN: shift-out-of-bounds in fs/gfs2/ops_fstype.c:295:19
[   76.373815] shift exponent 4294967287 is too large for 64-bit type &amp;#39;long unsigned int&amp;#39;&lt;/p&gt;
&lt;p&gt;After the patch, these complaints don&amp;#39;t appear, mount fails immediately
and we get an explanation in dmesg.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2022-49769</guid>
    </item>
  </channel>
</rss>
