Ben Wagner [Tue, 19 Jul 2022 17:02:40 +0000 (13:02 -0400)]
Validate entry_bytes_remaining in pax_attribute
The `size` attribute may contain a negative or too large value. Check
the range of the `entry_bytes_remaining` in `pax_attribute` the same way
as `header_common`. The test which is added passes both with and without
this change in a normal debug build. It is necessary to run with
`-fsanitize=undefined` to see that the undefined behavior is avoided.
David Macek [Sun, 17 Apr 2022 17:52:25 +0000 (19:52 +0200)]
archive_digest: Use correct providers with Windows Crypto
Trying to use SHA256, SHA384 or SHA512 with mtree when linked against
Windows Crypto would result in silent failure. The call to
`CryptCreateHash` would fail with 0x80090008. The docs[1] say that
these algorithms require a different crypto provider, so let's make
that a parameter for `win_crypto_init` and choose at the call site along
with the algorithm.
autotools: Fix static linking when openssl is enabled in windows
This adds Requires.private field in pkgconfig file. Using that field,
pkgconfig pulls all the private cflags or libs while static linking.
OpenSSL static libraries require some windows system libraies. Otherwise
static liking fails with libarchive.
This reverts commit 045e5c5a4460020e513516a5d1f3087094e67da3
For Windows platform, openssl 1.0.2 and earlier versions have
eay64 and eay32 libraries[1]. But from openssl 1.1.0 and above
versions have same library name[2] (libcrypto and libssl) like
other unix-like platforms.
Brad King [Wed, 16 Feb 2022 12:31:56 +0000 (07:31 -0500)]
windows: include archive_platform.h first in blake2s sources
Move the inclusion added by commit 90978db1 (windows: make sure we use
the right calling convention for libc, 2021-10-13, v3.6.0~39^2~1) to be
first. This is our convention in all other `.c` sources. It ensures
that our configured `_WIN32_WINNT` value is defined before including any
system headers.
RAR5 reader: add more checks for invalid extraction parameters
Some specially crafted files declare invalid extraction parameters that
can confuse the RAR5 reader.
One of the arguments is the declared window size parameter that the
archive file can declare for each file stored in the archive. Some
crafted files declare window size equal to 0, which is clearly wrong.
This commit adds additional safety checks decreasing the tolerance of
the RAR5 format.
RAR5 reader: fix invalid memory access in some files
RAR5 reader uses several variables to manage the window buffer during
extraction: the buffer itself (`window_buf`), the current size of the
window buffer (`window_size`), and a helper variable (`window_mask`)
that is used to constrain read and write offsets to the window buffer.
Some specially crafted files can force the unpacker to update the
`window_mask` variable to a value that is out of sync with current
buffer size. If the `window_mask` will be bigger than the actual buffer
size, then an invalid access operation can happen (SIGSEGV).
This commit ensures that if the `window_size` and `window_mask` will be
changed, the window buffer will be reallocated to the proper size, so no
invalid memory operation should be possible.
This commit contains a test file from OSSFuzz #30442.
Tim Kientzle [Wed, 2 Feb 2022 03:33:41 +0000 (19:33 -0800)]
Reorganize test code a bit
A few guiding principles:
* Each test source file includes ONLY "test.h" to make it easy
to create new tests.
* Each test suite has a "test.h" that includes "test_util/test_common.h"
to get access to all the common testing utility functions.
So "test_common.h" is then responsible for including
any smaller headers that declare specific pieces of
shared test functionality.
I've also pulled some test filtering logic that was _only_ used
in test_main.c into that file, and repurposed "test_utils.[ch]"
for common utility code. (Eventually, a lot of the assertion
helpers currently in "test_main.c" should probably be organized
into one or more source files of their own.)
Alex Richardson [Thu, 17 Sep 2020 17:28:17 +0000 (18:28 +0100)]
Avoid millions of rand() calls() when running tests
Many tests use a loop calling rand() to fill buffers with test data. As
these calls cannot be inlined, this adds up to noticeable overhead:
For example, running on QEMU RISC-V the test_write_format_7zip_large_copy
test took ~22 seconds before and with this change it's ~17 seconds.
This change uses a simpler xorshift64 random number generator that can be
inlined into the loop filling the data buffer. By default the seed for this
RNG is rand(), but it can be overwritten by setting the TEST_RANDOM_SEED
environment variable.
For a native build the difference is much less noticeable, but it's still
measurable: test_write_format_7zip_large_copy takes 314.9 ms ± 3.9 ms
before and 227.8 ms ± 5.8 ms after (i.e. 38% faster for that test).
projects / thirdparty / libarchive.git / log
