CVE-2022-50277

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: don&amp;#39;t allow journal inode to have encrypt flag<br /> <br /> Mounting a filesystem whose journal inode has the encrypt flag causes a<br /> NULL dereference in fscrypt_limit_io_blocks() when the &amp;#39;inlinecrypt&amp;#39;<br /> mount option is used.<br /> <br /> The problem is that when jbd2_journal_init_inode() calls bmap(), it<br /> eventually finds its way into ext4_iomap_begin(), which calls<br /> fscrypt_limit_io_blocks(). fscrypt_limit_io_blocks() requires that if<br /> the inode is encrypted, then its encryption key must already be set up.<br /> That&amp;#39;s not the case here, since the journal inode is never "opened" like<br /> a normal file would be. Hence the crash.<br /> <br /> A reproducer is:<br /> <br /> mkfs.ext4 -F /dev/vdb<br /> debugfs -w /dev/vdb -R "set_inode_field flags 0x80808"<br /> mount /dev/vdb /mnt -o inlinecrypt<br /> <br /> To fix this, make ext4 consider journal inodes with the encrypt flag to<br /> be invalid. (Note, maybe other flags should be rejected on the journal<br /> inode too. For now, this is just the minimal fix for the above issue.)<br /> <br /> I&amp;#39;ve marked this as fixing the commit that introduced the call to<br /> fscrypt_limit_io_blocks(), since that&amp;#39;s what made an actual crash start<br /> being possible. But this fix could be applied to any version of ext4<br /> that supports the encrypt feature.