From ea57b9aa2c3e1cdb667f8dd698314b1c36047018 Mon Sep 17 00:00:00 2001 From: Lasse Collin Date: Fri, 16 Sep 2022 17:08:53 +0300 Subject: Tests: Add a test file for lzma_index_append() integer overflow bug. This test fails before commit 18d7facd3802b55c287581405c4d49c98708c136. test_files.sh now runs xz -l for bad-3-index-uncomp-overflow.xz because only then the previously-buggy code path gets tested. Normal decompression doesn't use lzma_index_append() at all. Instead, lzma_index_hash functions are used and those already did the overflow check. --- tests/files/README | 10 ++++++++++ tests/files/bad-3-index-uncomp-overflow.xz | Bin 0 -> 132 bytes 2 files changed, 10 insertions(+) create mode 100644 tests/files/bad-3-index-uncomp-overflow.xz (limited to 'tests/files') diff --git a/tests/files/README b/tests/files/README index ba05aba5..3e550dfe 100644 --- a/tests/files/README +++ b/tests/files/README @@ -209,6 +209,16 @@ file gets rejected specifically due to Unpadded Size having an invalid value. + bad-3-index-uncomp-overflow.xz has Index whose Uncompressed Size + fields have huge values whose sum exceeds the maximum allowed size + of 2^63 - 1 bytes. In this file the sum is exactly 2^64. + lzma_index_append() in liblzma <= 5.2.6 lacks the integer overflow + check for the uncompressed size and thus doesn't catch the error + when decoding the Index field in this file. This makes "xz -l" + not detect the error and will display 0 as the uncompressed size. + Note that regular decompression isn't affected by this bug because + it uses lzma_index_hash_append() instead. + bad-2-compressed_data_padding.xz has non-null byte in the padding of the Compressed Data field of the first Block. diff --git a/tests/files/bad-3-index-uncomp-overflow.xz b/tests/files/bad-3-index-uncomp-overflow.xz new file mode 100644 index 00000000..e1440ec6 Binary files /dev/null and b/tests/files/bad-3-index-uncomp-overflow.xz differ -- cgit v1.2.3