Avoid overflow when reading corrupt cpio archive

A cpio "newc" archive with a namelength of "FFFFFFFF", if read on a
system with a 32-bit size_t, would result in namelength + name_pad
overflowing 32 bits and libarchive attempting to copy 2^32-1 bytes
from a 2-byte buffer, with appropriately hilarious results.

Check for this overflow and fail; there's no legitimate reason for a
cpio archive to contain a file with a name over 4 billion characters
in length.

Reported by:	Eyal Itkin
Security:	Corrupt archives can cause libarchive to crash on
		32-bit platforms.
Sponsored by:	Tarsnap Backup Inc.

diff --git a/libarchive/archive_read_support_format_cpio.c b/libarchive/archive_read_support_format_cpio.c
index ad9f782de48884cc1f22b221ca34e390b0f01b68..67d5b21eebbe4c4f21c821766676baba537d92d5 100644 (file)
--- a/libarchive/archive_read_support_format_cpio.c
+++ b/libarchive/archive_read_support_format_cpio.c
@@ -633,6 +633,13 @@ header_newc(struct archive_read *a, struct cpio *cpio,
        /* Pad name to 2 more than a multiple of 4. */
        *name_pad = (2 - *namelength) & 3;
 
+       /* Make sure that the padded name length fits into size_t. */
+       if (*name_pad > SIZE_MAX - *namelength) {
+               archive_set_error(&a->archive, ARCHIVE_ERRNO_FILE_FORMAT,
+                   "cpio archive has invalid namelength");
+               return (ARCHIVE_FATAL);
+       }
+
        /*
         * Note: entry_bytes_remaining is at least 64 bits and
         * therefore guaranteed to be big enough for a 33-bit file