]> git.ipfire.org Git - thirdparty/libarchive.git/commit
RAR5 reader: don't try to unpack entries marked as directories 1190/head
authorGrzegorz Antoniak <ga@anadoxin.org>
Sun, 5 May 2019 06:16:03 +0000 (08:16 +0200)
committerGrzegorz Antoniak <ga@anadoxin.org>
Mon, 6 May 2019 08:04:47 +0000 (10:04 +0200)
commitf7b1d38b31877f39ea979722ddf1ef072a6c3af4
treebff37a938fa791c583b21065eafc2d8a81f72ea1
parent0ba5492a09202514bbf3c9a422997a9800b24b8e
RAR5 reader: don't try to unpack entries marked as directories

RAR5 structure contains two places where a file can be marked as a
directory. First place is inside the file_flags field in FILE and
SERVICE base blocks, and the second place is inside file_attributes
bitfield also in the same base blocks.

The first directory flag was used to decide if the reader should
allocate any memory for the dictionary buffer needed to unpack the
files. Because if the file is actually a directory, then there should be
nothing to unpack, so if a file was marked as a directory here, the
reader did not allocate any dictionary buffer.

The second directory flag was used to indicate what file attributes
should be passed to the caller. So this second directory flag was used
as an actual indicator what the caller should do during archive
unpacking: should it treat it as a directory, or should it treat it as a
file.

Because of this situation, it was possible to declare a file as a
directory in the file_flags field, but do not declare it as a directory
in the second field, also adding a compressed stream to the FILE/SERVICE
base block. This situation was leading to a condition where the reader
was trying to use unallocated/already freed memory (because it did not
allocate a new dictionary buffer due to the directory flag set in
file_flags).

This commit fixes it so that the reader will check if it tries to
decompress a FILE/SERVICE block that has been declared as a directory in
the file_flags field. If the check will evaluate to true, it will return
an ARCHIVE_FAILED code, because it's not a valid action to take, and
shouldn't exist in valid archives at all.

Also added a unit test for this issue.

This should fix OSSFuzz issue #14574.

This commit also has influenced some of the other unit tests, because it
turned out the sample files used in other tests also did have
inconsistent directory flags in the file_flags and file_attributes
fields. So, some assertions in affected test cases have been changed to
be more relaxed, but still functional.
libarchive/archive_read_support_format_rar5.c
libarchive/test/test_read_format_rar5.c
libarchive/test/test_read_format_rar5_nonempty_dir_stream.rar.uu [new file with mode: 0644]