summaryrefslogtreecommitdiffstats
path: root/lib/decompress_unxz.c
diff options
context:
space:
mode:
authorLasse Collin <lasse.collin@tukaani.org>2021-10-10 23:31:39 +0200
committerGao Xiang <hsiangkao@linux.alibaba.com>2021-10-19 17:44:30 +0200
commit83d3c4f22a36d005b55f44628f46cc0d319a75e8 (patch)
tree148fa15f84c3fcea07fa515dcc305494417a46b0 /lib/decompress_unxz.c
parenterofs: introduce readmore decompression strategy (diff)
downloadlinux-83d3c4f22a36d005b55f44628f46cc0d319a75e8.tar.xz
linux-83d3c4f22a36d005b55f44628f46cc0d319a75e8.zip
lib/xz: Avoid overlapping memcpy() with invalid input with in-place decompression
With valid files, the safety margin described in lib/decompress_unxz.c ensures that these buffers cannot overlap. But if the uncompressed size of the input is larger than the caller thought, which is possible when the input file is invalid/corrupt, the buffers can overlap. Obviously the result will then be garbage (and usually the decoder will return an error too) but no other harm will happen when such an over-run occurs. This change only affects uncompressed LZMA2 chunks and so this should have no effect on performance. Link: https://lore.kernel.org/r/20211010213145.17462-2-xiang@kernel.org Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Diffstat (limited to 'lib/decompress_unxz.c')
-rw-r--r--lib/decompress_unxz.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/lib/decompress_unxz.c b/lib/decompress_unxz.c
index a2f38e23004a..f7a3dc13316a 100644
--- a/lib/decompress_unxz.c
+++ b/lib/decompress_unxz.c
@@ -167,7 +167,7 @@
* memeq and memzero are not used much and any remotely sane implementation
* is fast enough. memcpy/memmove speed matters in multi-call mode, but
* the kernel image is decompressed in single-call mode, in which only
- * memcpy speed can matter and only if there is a lot of uncompressible data
+ * memmove speed can matter and only if there is a lot of uncompressible data
* (LZMA2 stores uncompressible chunks in uncompressed form). Thus, the
* functions below should just be kept small; it's probably not worth
* optimizing for speed.