CVE-2023-52497

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: fix lz4 inplace decompression<br /> <br /> Currently EROFS can map another compressed buffer for inplace<br /> decompression, that was used to handle the cases that some pages of<br /> compressed data are actually not in-place I/O.<br /> <br /> However, like most simple LZ77 algorithms, LZ4 expects the compressed<br /> data is arranged at the end of the decompressed buffer and it<br /> explicitly uses memmove() to handle overlapping:<br /> __________________________________________________________<br /> |_ direction of decompression --&gt; ____ |_ compressed data _|<br /> <br /> Although EROFS arranges compressed data like this, it typically maps two<br /> individual virtual buffers so the relative order is uncertain.<br /> Previously, it was hardly observed since LZ4 only uses memmove() for<br /> short overlapped literals and x86/arm64 memmove implementations seem to<br /> completely cover it up and they don&amp;#39;t have this issue. Juhyung reported<br /> that EROFS data corruption can be found on a new Intel x86 processor.<br /> After some analysis, it seems that recent x86 processors with the new<br /> FSRM feature expose this issue with "rep movsb".<br /> <br /> Let&amp;#39;s strictly use the decompressed buffer for lz4 inplace<br /> decompression for now. Later, as an useful improvement, we could try<br /> to tie up these two buffers together in the correct order.