CVE-2023-52497

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

Notes