CVE-2022-49769

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gfs2: Check sb_bsize_shift after reading superblock<br /> <br /> Fuzzers like to scribble over sb_bsize_shift but in reality it&amp;#39;s very<br /> unlikely that this field would be corrupted on its own. Nevertheless it<br /> should be checked to avoid the possibility of messy mount errors due to<br /> bad calculations. It&amp;#39;s always a fixed value based on the block size so<br /> we can just check that it&amp;#39;s the expected value.<br /> <br /> Tested with:<br /> <br /> mkfs.gfs2 -O -p lock_nolock /dev/vdb<br /> for i in 0 -1 64 65 32 33; do<br /> gfs2_edit -p sb field sb_bsize_shift $i /dev/vdb<br /> mount /dev/vdb /mnt/test &amp;&amp; umount /mnt/test<br /> done<br /> <br /> Before this patch we get a withdraw after<br /> <br /> [ 76.413681] gfs2: fsid=loop0.0: fatal: invalid metadata block<br /> [ 76.413681] bh = 19 (type: exp=5, found=4)<br /> [ 76.413681] function = gfs2_meta_buffer, file = fs/gfs2/meta_io.c, line = 492<br /> <br /> and with UBSAN configured we also get complaints like<br /> <br /> [ 76.373395] UBSAN: shift-out-of-bounds in fs/gfs2/ops_fstype.c:295:19<br /> [ 76.373815] shift exponent 4294967287 is too large for 64-bit type &amp;#39;long unsigned int&amp;#39;<br /> <br /> After the patch, these complaints don&amp;#39;t appear, mount fails immediately<br /> and we get an explanation in dmesg.