CVE-2022-50428

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix off-by-one errors in fast-commit block filling<br /> <br /> Due to several different off-by-one errors, or perhaps due to a late<br /> change in design that wasn&amp;#39;t fully reflected in the code that was<br /> actually merged, there are several very strange constraints on how<br /> fast-commit blocks are filled with tlv entries:<br /> <br /> - tlvs must start at least 10 bytes before the end of the block, even<br /> though the minimum tlv length is 8. Otherwise, the replay code will<br /> ignore them. (BUG: ext4_fc_reserve_space() could violate this<br /> requirement if called with a len of blocksize - 9 or blocksize - 8.<br /> Fortunately, this doesn&amp;#39;t seem to happen currently.)<br /> <br /> - tlvs must end at least 1 byte before the end of the block. Otherwise<br /> the replay code will consider them to be invalid. This quirk<br /> contributed to a bug (fixed by an earlier commit) where uninitialized<br /> memory was being leaked to disk in the last byte of blocks.<br /> <br /> Also, strangely these constraints don&amp;#39;t apply to the replay code in<br /> e2fsprogs, which will accept any tlvs in the blocks (with no bounds<br /> checks at all, but that is a separate issue...).<br /> <br /> Given that this all seems to be a bug, let&amp;#39;s fix it by just filling<br /> blocks with tlv entries in the natural way.<br /> <br /> Note that old kernels will be unable to replay fast-commit journals<br /> created by kernels that have this commit.