diff options
| author | Lasse Collin <lasse.collin@tukaani.org> | 2021-10-11 00:31:39 +0300 |
|---|---|---|
| committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2021-11-18 16:03:58 +0300 |
| commit | aa5d35e350f6587a17e7b17cc26eb0bfd7dda04c (patch) | |
| tree | ed44e312e82158cedfa55b4ced2416d20bb7ec8c /lib/decompress_unxz.c | |
| parent | cad55afe37c9d4c796d9b2f9531e96ed4204d631 (diff) | |
| download | linux-aa5d35e350f6587a17e7b17cc26eb0bfd7dda04c.tar.xz | |
lib/xz: Avoid overlapping memcpy() with invalid input with in-place decompression
[ Upstream commit 83d3c4f22a36d005b55f44628f46cc0d319a75e8 ]
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>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Diffstat (limited to 'lib/decompress_unxz.c')
| -rw-r--r-- | lib/decompress_unxz.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/lib/decompress_unxz.c b/lib/decompress_unxz.c index 25d59a95bd66..abea25310ac7 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. |