Fix segfault in iso9660 reader

Some odd ISO images do some funny things with RockRidge and Joliet data.
In this particular case, Joliet is used on the CD image, but the first
directory record has no RockRidge data. However, subsequent directory
entries (in the Joliet volume descriptor!) have RockRidge data attached,
although what is noticeably missing are type "NM" or name entries.

This causes seenRockridge to get flipped on, which makes the bad
assumption that seenJoliet is false.  This means that when we reach the
code searching for the "rr_moved" special file, we strcmp() against NULL
because our filename is really in file->utf16be_bytes.

This is by far the easiest fix (and likely most correct fix) to this
madness; I have no idea whether a UTF-16 encoded "rr_moved" file can
even exist with whatever mastering software was used on this ISO.

Also note that if you explicitly disable Joliet processing, you get a
very different file listing on this ISO; apparently this is a cleaver
way to hide files from prying eyes in the Windows world:

    $ ./bsdtar -t --options 'iso9660:joliet' -f example.iso | wc -l
    24
    $ ./bsdtar -t --options 'iso9660:!joliet' -f example.iso | wc -l
    3060

diff --git a/libarchive/archive_read_support_format_iso9660.c b/libarchive/archive_read_support_format_iso9660.c
index d56c185abaf95c593c4274a76d094d8fb740718f..a165524017e3fb95bc04b5fa5249f495ec639fc9 100644 (file)
--- a/libarchive/archive_read_support_format_iso9660.c
+++ b/libarchive/archive_read_support_format_iso9660.c
@@ -1933,6 +1933,7 @@ parse_file_info(struct archive_read *a, struct file_info *parent,
        if (iso9660->seenRockridge) {
                if (parent != NULL && parent->parent == NULL &&
                    (flags & 0x02) && iso9660->rr_moved == NULL &&
+                   file->name.s &&
                    (strcmp(file->name.s, "rr_moved") == 0 ||
                     strcmp(file->name.s, ".rr_moved") == 0)) {
                        iso9660->rr_moved = file;