hitoshura25/cvefixes huggingface dataset:
CVE-2016-1541 (C, published 2016-05-07T10:59Z)
Description: value: Heap-based buffer overflow in the zip_read_mac_metadata function in archive_read_support_format_zip.c in libarchive before 3.2.0 allows remote attackers to execute arbitrary code via crafted entry-size values in a ZIP archive.
Severity: MEDIUM (CVSS v3 base score: 8.8)
Weakness: CWE-20 \u2014 Improper Input Validation
The product receives input or data, but it does
        not validate or incorrectly validates that the input has the
        properties that are required to process the data safely and
        correctly.
Repository: https://github.com/libarchive/libarchive
Files changed:
libarchive/archive_read_support_format_zip.c
Commit message: Issue #656:  Fix CVE-2016-1541, VU#862384

When reading OS X metadata entries in Zip archives that were stored
without compression, libarchive would use the uncompressed entry size
to allocate a buffer but would use the compressed entry size to limit
the amount of data copied into that buffer.  Since the compressed
and uncompressed sizes are provided by data in the archive itself,
an attacker could manipulate these values to write data beyond
the end of the allocated buffer.

This fix provides three new checks to guard against such
manipulation and to make libarchive generally more robust when
handling this type of entry:
 1. If an OS X metadata entry is stored without compression,
    abort the entire archive if the compressed and uncompressed
    data sizes do not match.
 2. When sanity-checking the size of an OS X metadata entry,
    abort this entry if either the compressed or uncompressed
    size is larger than 4MB.
 3. When copying data into the allocated buffer, check the copy
    size against both the compressed entry size and uncompressed
    entry size.


Vulnerable code:

Fixed code:
		if (rsrc->uncompressed_size != rsrc->compressed_size) {
			archive_set_error(&a->archive, ARCHIVE_ERRNO_FILE_FORMAT,
			    "Malformed OS X metadata entry: inconsistent size");
			return (ARCHIVE_FATAL);
		}
	if (rsrc->compressed_size > (4 * 1024 * 1024)) {
		archive_set_error(&a->archive, ARCHIVE_ERRNO_FILE_FORMAT,
		    "Mac metadata is too large: %jd > 4M bytes",
		    (intmax_t)rsrc->compressed_size);
		return (ARCHIVE_WARN);
	}
			if ((size_t)bytes_avail > metadata_bytes)
				bytes_avail = metadata_bytes;
CVE-2016-4300 (C, published 2016-09-21T14:25Z)
Description: value: Integer overflow in the read_SubStreamsInfo function in archive_read_support_format_7zip.c in libarchive before 3.2.1 allows remote attackers to execute arbitrary code via a 7zip file with a large number of substreams, which triggers a heap-based buffer overflow.
Severity: MEDIUM (CVSS v3 base score: 7.8)
Weakness: CWE-190 \u2014 Integer Overflow or Wraparound
The product performs a calculation that can
         produce an integer overflow or wraparound when the logic
         assumes that the resulting value will always be larger than
         the original value. This occurs when an integer value is
         incremented to a value that is too large to store in the
         associated representation. When this occurs, the value may
         become a very small or negative number.
Repository: https://github.com/libarchive/libarchive
Files changed:
libarchive/archive_read_support_format_7zip.c
Commit message: Issue #718: Fix TALOS-CAN-152

If a 7-Zip archive declares a rediculously large number of substreams,
it can overflow an internal counter, leading a subsequent memory
allocation to be too small for the substream data.

Thanks to the Open Source and Threat Intelligence project at Cisco
for reporting this issue.


Vulnerable code:

Fixed code:
			if (unpack_streams > SIZE_MAX - UMAX_ENTRY) {
				return (-1);
			}
CVE-2016-4301 (C, published 2016-09-21T14:25Z)
Description: value: Stack-based buffer overflow in the parse_device function in archive_read_support_format_mtree.c in libarchive before 3.2.1 allows remote attackers to execute arbitrary code via a crafted mtree file.
Severity: MEDIUM (CVSS v3 base score: 7.8)
Weakness: CWE-119 \u2014 Improper Restriction of Operations within the Bounds of a Memory Buffer
The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data.
Repository: https://github.com/libarchive/libarchive
Files changed:
libarchive/archive_read_support_format_mtree.c
Commit message: Fix libarchive/archive_read_support_format_mtree.c:1388:11: error: array subscript is above array bounds


Vulnerable code:
			numbers[argc++] = (unsigned long)mtree_atol(&p);
			if (argc > MAX_PACK_ARGS) {

Fixed code:
			if (argc >= MAX_PACK_ARGS) {
			numbers[argc++] = (unsigned long)mtree_atol(&p);
CVE-2016-4302 (C, published 2016-09-21T14:25Z)
Description: value: Heap-based buffer overflow in the parse_codes function in archive_read_support_format_rar.c in libarchive before 3.2.1 allows remote attackers to execute arbitrary code via a RAR file with a zero-sized dictionary.
Severity: MEDIUM (CVSS v3 base score: 7.8)
Weakness: CWE-119 \u2014 Improper Restriction of Operations within the Bounds of a Memory Buffer
The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data.
Repository: https://github.com/libarchive/libarchive
Files changed:
libarchive/archive_read_support_format_rar.c
Commit message: Issue 719:  Fix for TALOS-CAN-154

A RAR file with an invalid zero dictionary size was not being
rejected, leading to a zero-sized allocation for the dictionary
storage which was then overwritten during the dictionary initialization.

Thanks to the Open Source and Threat Intelligence project at Cisco for
reporting this.


Vulnerable code:

Fixed code:
      if (rar->dictionary_size == 0) {
	      archive_set_error(&a->archive, ARCHIVE_ERRNO_FILE_FORMAT,
                          "Invalid zero dictionary size");
	      return (ARCHIVE_FATAL);
      }
CVE-2016-5844 (C, published 2016-09-21T14:25Z)
Description: value: Integer overflow in the ISO parser in libarchive before 3.2.1 allows remote attackers to cause a denial of service (application crash) via a crafted ISO file.
Severity: MEDIUM (CVSS v3 base score: 6.5)
Weakness: CWE-190 \u2014 Integer Overflow or Wraparound
The product performs a calculation that can
         produce an integer overflow or wraparound when the logic
         assumes that the resulting value will always be larger than
         the original value. This occurs when an integer value is
         incremented to a value that is too large to store in the
         associated representation. When this occurs, the value may
         become a very small or negative number.
Repository: https://github.com/libarchive/libarchive
Files changed:
libarchive/archive_read_support_format_iso9660.c
Commit message: Issue 717:  Fix integer overflow when computing location of volume descriptor

The multiplication here defaulted to 'int' but calculations
of file positions should always use int64_t.  A simple cast
suffices to fix this since the base location is always 32 bits
for ISO, so multiplying by the sector size will never overflow
a 64-bit integer.


Vulnerable code:
	skipsize = LOGICAL_BLOCK_SIZE * vd->location;
		skipsize = LOGICAL_BLOCK_SIZE * vd->location;

Fixed code:
	skipsize = LOGICAL_BLOCK_SIZE * (int64_t)vd->location;
		skipsize = LOGICAL_BLOCK_SIZE * (int64_t)vd->location;
CVE-2016-8687 (C, published 2017-02-15T19:59Z)
Description: value: Stack-based buffer overflow in the safe_fprintf function in tar/util.c in libarchive 3.2.1 allows remote attackers to cause a denial of service via a crafted non-printable multibyte character in a filename.
Severity: MEDIUM (CVSS v3 base score: 7.5)
Weakness: CWE-119 \u2014 Improper Restriction of Operations within the Bounds of a Memory Buffer
The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data.
Repository: https://github.com/libarchive/libarchive
Files changed:
tar/util.c
Commit message: Issue #767:  Buffer overflow printing a filename

The safe_fprintf function attempts to ensure clean output for an
arbitrary sequence of bytes by doing a trial conversion of the
multibyte characters to wide characters -- if the resulting wide
character is printable then we pass through the corresponding bytes
unaltered, otherwise, we convert them to C-style ASCII escapes.

The stack trace in Issue #767 suggest that the 20-byte buffer
was getting overflowed trying to format a non-printable multibyte
character.  This should only happen if there is a valid multibyte
character of more than 5 bytes that was unprintable.  (Each byte
would get expanded to a four-charcter octal-style escape of the form
"\123" resulting in >20 characters for the >5 byte multibyte character.)

I've not been able to reproduce this, but have expanded the conversion
buffer to 128 bytes on the belief that no multibyte character set
has a single character of more than 32 bytes.


Vulnerable code:
		if (i > (sizeof(outbuff) - 20)) {

Fixed code:
		if (i > (sizeof(outbuff) - 128)) {
CVE-2016-8689 (C, published 2017-02-15T19:59Z)
Description: value: The read_Header function in archive_read_support_format_7zip.c in libarchive 3.2.1 allows remote attackers to cause a denial of service (out-of-bounds read) via multiple EmptyStream attributes in a header in a 7zip archive.
Severity: MEDIUM (CVSS v3 base score: 7.5)
Weakness: CWE-125 \u2014 Out-of-bounds Read
The product reads data past the end, or before the beginning, of the intended buffer.
Repository: https://github.com/libarchive/libarchive
Files changed:
libarchive/archive_read_support_format_7zip.c
Commit message: Issue 761:  Heap overflow reading corrupted 7Zip files

The sample file that demonstrated this had multiple 'EmptyStream'
attributes.  The first one ended up being used to calculate
certain statistics, then was overwritten by the second which
was incompatible with those statistics.

The fix here is to reject any header with multiple EmptyStream
attributes.  While here, also reject headers with multiple
EmptyFile, AntiFile, Name, or Attributes markers.


Vulnerable code:

Fixed code:
			if (h->emptyStreamBools != NULL)
				return (-1);
			if (h->emptyFileBools != NULL)
				return (-1);
			if (h->antiBools != NULL)
				return (-1);
			if (zip->entry_names != NULL)
				return (-1);
			if (h->attrBools != NULL)
				return (-1);
CVE-2017-14166 (C, published 2017-09-06T18:29Z)
Description: value: libarchive 3.3.2 allows remote attackers to cause a denial of service (xml_data heap-based buffer over-read and application crash) via a crafted xar archive, related to the mishandling of empty strings in the atol8 function in archive_read_support_format_xar.c.
Severity: MEDIUM (CVSS v3 base score: 6.5)
Weakness: CWE-125 \u2014 Out-of-bounds Read
The product reads data past the end, or before the beginning, of the intended buffer.
Repository: https://github.com/libarchive/libarchive
Files changed:
libarchive/archive_read_support_format_xar.c
Commit message: Do something sensible for empty strings to make fuzzers happy.


Vulnerable code:

Fixed code:
	if (char_cnt == 0)
		return (0);


	if (char_cnt == 0)
		return (0);
CVE-2017-14502 (C, published 2017-09-17T18:29Z)
Description: value: read_header in archive_read_support_format_rar.c in libarchive 3.3.2 suffers from an off-by-one error for UTF-16 names in RAR archives, leading to an out-of-bounds read in archive_read_format_rar_read_header.
Severity: MEDIUM (CVSS v3 base score: 7.5)
Weakness: CWE-125 \u2014 Out-of-bounds Read
The product reads data past the end, or before the beginning, of the intended buffer.
Repository: https://github.com/libarchive/libarchive
Files changed:
libarchive/archive_read_support_format_rar.c
Commit message: Avoid a read off-by-one error for UTF16 names in RAR archives.

Reported-By: OSS-Fuzz issue 573


Vulnerable code:
      filename[filename_size++] = '\0';

Fixed code:
      /*
       * Do not increment filename_size here as the computations below
       * add the space for the terminating NUL explicitly.
       */
      filename[filename_size] = '\0';
CVE-2017-14502 (C, published 2017-09-17T18:29Z)
Description: value: read_header in archive_read_support_format_rar.c in libarchive 3.3.2 suffers from an off-by-one error for UTF-16 names in RAR archives, leading to an out-of-bounds read in archive_read_format_rar_read_header.
Severity: MEDIUM (CVSS v3 base score: 7.5)
Weakness: CWE-193 \u2014 Off-by-one Error
A product calculates or uses an incorrect maximum or minimum value that is 1 more, or 1 less, than the correct value.
Repository: https://github.com/libarchive/libarchive
Files changed:
libarchive/archive_read_support_format_rar.c
Commit message: Avoid a read off-by-one error for UTF16 names in RAR archives.

Reported-By: OSS-Fuzz issue 573


Vulnerable code:
      filename[filename_size++] = '\0';

Fixed code:
      /*
       * Do not increment filename_size here as the computations below
       * add the space for the terminating NUL explicitly.
       */
      filename[filename_size] = '\0';
CVE-2017-5601 (C, published 2017-01-27T22:59Z)
Description: value: An error in the lha_read_file_header_1() function (archive_read_support_format_lha.c) in libarchive 3.2.2 allows remote attackers to trigger an out-of-bounds read memory access and subsequently cause a crash via a specially crafted archive.
Severity: MEDIUM (CVSS v3 base score: 7.5)
Weakness: CWE-125 \u2014 Out-of-bounds Read
The product reads data past the end, or before the beginning, of the intended buffer.
Repository: https://github.com/libarchive/libarchive
Files changed:
libarchive/archive_read_support_format_lha.c
Commit message: Fail with negative lha->compsize in lha_read_file_header_1()
Fixes a heap buffer overflow reported in Secunia SA74169


Vulnerable code:

Fixed code:
	if (lha->compsize < 0)
		goto invalid;	/* Invalid compressed file size */
CVE-2019-11463 (C, published 2019-04-23T03:29Z)
Description: value: A memory leak in archive_read_format_zip_cleanup in archive_read_support_format_zip.c in libarchive 3.3.4-dev allows remote attackers to cause a denial of service via a crafted ZIP file because of a HAVE_LZMA_H typo. NOTE: this only affects users who downloaded the development code from GitHub. Users of the product's official releases are unaffected.
Severity: MEDIUM (CVSS v3 base score: 5.5)
Weakness: CWE-401 \u2014 Missing Release of Memory after Effective Lifetime
The product does not sufficiently track and release allocated memory after it has been used, which slowly consumes remaining memory.
Repository: https://github.com/libarchive/libarchive
Files changed:
libarchive/archive_read_support_format_zip.c
Commit message: Fix typo in preprocessor macro in archive_read_format_zip_cleanup()

Frees lzma_stream on cleanup()

Fixes #1165


Vulnerable code:
#if HAVA_LZMA_H && HAVE_LIBLZMA

Fixed code:
#if HAVE_LZMA_H && HAVE_LIBLZMA
CVE-2019-18408 (C, published 2019-10-24T14:15Z)
Description: value: archive_read_format_rar_read_data in archive_read_support_format_rar.c in libarchive before 3.4.0 has a use-after-free in a certain ARCHIVE_FAILED situation, related to Ppmd7_DecodeSymbol.
Severity: MEDIUM (CVSS v3 base score: 7.5)
Weakness: CWE-416 \u2014 Use After Free
The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer.
Repository: https://github.com/libarchive/libarchive
Files changed:
libarchive/archive_read_support_format_rar.c
Commit message: RAR reader: fix use after free

If read_data_compressed() returns ARCHIVE_FAILED, the caller is allowed
to continue with next archive headers. We need to set rar->start_new_table
after the ppmd7_context got freed, otherwise it won't be allocated again.

Reported by: OSS-Fuzz issue 2582


Vulnerable code:
    if (ret != ARCHIVE_OK && ret != ARCHIVE_WARN)

Fixed code:
    if (ret != ARCHIVE_OK && ret != ARCHIVE_WARN) {
      rar->start_new_table = 1;
    }
CVE-2019-19221 (C, published 2019-11-21T23:15Z)
Description: value: In Libarchive 3.4.0, archive_wstring_append_from_mbs in archive_string.c has an out-of-bounds read because of an incorrect mbrtowc or mbtowc call. For example, bsdtar crashes via a crafted archive.
Severity: LOW (CVSS v3 base score: 5.5)
Weakness: CWE-125 \u2014 Out-of-bounds Read
The product reads data past the end, or before the beginning, of the intended buffer.
Repository: https://github.com/libarchive/libarchive
Files changed:
libarchive/archive_string.c
Commit message: Bugfix and optimize archive_wstring_append_from_mbs()

The cal to mbrtowc() or mbtowc() should read up to mbs_length
bytes and not wcs_length. This avoids out-of-bounds reads.

mbrtowc() and mbtowc() return (size_t)-1 wit errno EILSEQ when
they encounter an invalid multibyte character and (size_t)-2 when
they they encounter an incomplete multibyte character. As we return
failure and all our callers error out it makes no sense to continue
parsing mbs.

As we allocate `len` wchars at the beginning and each wchar has
at least one byte, there will never be need to grow the buffer,
so the code can be left out. On the other hand, we are always
allocatng more memory than we need.

As long as wcs_length == mbs_length == len we can omit wcs_length.
We keep the old code commented if we decide to save memory and
use autoexpanding wcs_length in the future.

Fixes #1276


Vulnerable code:
	size_t wcs_length = len;
	if (NULL == archive_wstring_ensure(dest, dest->length + wcs_length + 1))
		r = mbrtowc(wcs, mbs, wcs_length, &shift_state);
		r = mbtowc(wcs, mbs, wcs_length);
			if (errno == EILSEQ) {
				++mbs;
				--mbs_length;
				continue;
			} else
				break;
		wcs_length--;

Fixed code:
	// size_t wcs_length = len;
	/*
	 * As we decided to have wcs_length == mbs_length == len
	 * we can use len here instead of wcs_length
	 */
	if (NULL == archive_wstring_ensure(dest, dest->length + len + 1))
		/*
		 * The buffer we allocated is always big enough.
		 * Keep this code path in a comment if we decide to choose
		 * smaller wcs_length in the future
		 */
/*
*/
		r = mbrtowc(wcs, mbs, mbs_length, &shift_state);
		r = mbtowc(wcs, mbs, mbs_length);
			break;
		// wcs_length--;
CVE-2020-21674 (C, published 2020-10-15T15:15Z)
Description: value: Heap-based buffer overflow in archive_string_append_from_wcs() (archive_string.c) in libarchive-3.4.1dev allows remote attackers to cause a denial of service (out-of-bounds write in heap memory resulting into a crash) via a crafted archive file. NOTE: this only affects users who downloaded the development code from GitHub. Users of the product's official releases are unaffected.
Severity: MEDIUM (CVSS v3 base score: 6.5)
Weakness: CWE-787 \u2014 Out-of-bounds Write
The product writes data past the end, or before the beginning, of the intended buffer.
Repository: https://github.com/libarchive/libarchive
Files changed:
libarchive/archive_string.c
Commit message: Fix a possible heap-buffer-overflow in archive_string_append_from_wcs()

When we grow the archive_string buffer, we have to make sure it fits
at least one maximum-sized multibyte character in the current locale
and the null character.

Fixes #1298


Vulnerable code:
			    as->length + len * 2 + 1) == NULL)
			    as->length + len * 2 + 1) == NULL)

Fixed code:
#undef max
#define max(a, b)       ((a)>(b)?(a):(b))

			    as->length + max(len * 2,
			    (size_t)MB_CUR_MAX) + 1) == NULL)
			    as->length + max(len * 2,
			    (size_t)MB_CUR_MAX) + 1) == NULL)
CVE-2021-23177 (C, published 2022-08-23T16:15Z)
Description: value: An improper link resolution flaw while extracting an archive can lead to changing the access control list (ACL) of the target of the link. An attacker may provide a malicious archive to a victim user, who would trigger this flaw when trying to extract the archive. A local attacker may use this flaw to change the ACL of a file on the system and gain more privileges.
Severity: nan (CVSS v3 base score: 7.8)
Weakness: CWE-59 \u2014 Improper Link Resolution Before File Access ('Link Following')
The product attempts to access a file based on the filename, but it does not properly prevent that filename from identifying a link or shortcut that resolves to an unintended resource.
Repository: https://github.com/libarchive/libarchive
Files changed:
libarchive/archive_disk_acl_freebsd.c
libarchive/archive_disk_acl_linux.c
libarchive/archive_disk_acl_sunos.c
Commit message: Fix handling of symbolic link ACLs

On Linux ACLs on symbolic links are not supported.
We must avoid calling acl_set_file() on symbolic links as their
targets are modified instead.

While here, do not try to set default ACLs on non-directories.

Fixes #1565


Vulnerable code:
    struct archive_acl *abstract_acl,
	else if (acl_set_file(name, acl_type, acl) != 0)
			ret = set_acl(a, fd, name, abstract_acl,
			ret = set_acl(a, fd, name, abstract_acl,
		ret = set_acl(a, fd, name, abstract_acl,
    struct archive_acl *abstract_acl,
			ret = set_acl(a, fd, name, abstract_acl,
			ret = set_acl(a, fd, name, abstract_acl,
    struct archive_acl *abstract_acl,

		ret = set_acl(a, fd, name, abstract_acl,
		ret = set_acl(a, fd, name, abstract_acl,

Fixed code:
    struct archive_acl *abstract_acl, __LA_MODE_T mode,
	if (acl_type == ACL_TYPE_DEFAULT && !S_ISDIR(mode)) {
		errno = EINVAL;
		archive_set_error(a, errno,
		    "Cannot set default ACL on non-directory");
		return (ARCHIVE_WARN);
	}

	else if (S_ISLNK(mode)) {
	    /* acl_set_file() follows symbolic links, skip */
	    ret = ARCHIVE_OK;
	} else if (acl_set_file(name, acl_type, acl) != 0)
			ret = set_acl(a, fd, name, abstract_acl, mode,
			ret = set_acl(a, fd, name, abstract_acl, mode,
		ret = set_acl(a, fd, name, abstract_acl, mode,
	if (S_ISLNK(mode)) {
		/* Linux does not support RichACLs on symbolic links */
		return (ARCHIVE_OK);
	}

    struct archive_acl *abstract_acl, __LA_MODE_T mode,
	if (S_ISLNK(mode)) {
		/* Linux does not support ACLs on symbolic links */
		return (ARCHIVE_OK);
	}

	if (acl_type == ACL_TYPE_DEFAULT && !S_ISDIR(mode)) {
		errno = EINVAL;
		archive_set_error(a, errno,
		    "Cannot set default ACL on non-directory");
		return (ARCHIVE_WARN);
	}

			ret = set_acl(a, fd, name, abstract_acl, mode,
			ret = set_acl(a, fd, name, abstract_acl, mode,
    struct archive_acl *abstract_acl, __LA_MODE_T mode,
        if (S_ISLNK(mode)) {
                /* Skip ACLs on symbolic links */
		ret = ARCHIVE_OK;
		goto exit_free;
        }

		ret = set_acl(a, fd, name, abstract_acl, mode,
		ret = set_acl(a, fd, name, abstract_acl, mode,
CVE-2024-26256 (C, published 2024-04-09T17:15Z)
Description: value: libarchive Remote Code Execution Vulnerability
Severity: nan (CVSS v3 base score: 7.8)
Weakness: NVD-CWE-noinfo \u2014 Insufficient Information
There is insufficient information about the issue to classify it; details are unkown or unspecified.
Repository: https://github.com/libarchive/libarchive
Files changed:
libarchive/archive_read_support_format_rar.c
Commit message: fix: OOB in rar e8 filter (#2135)

This patch fixes an out-of-bound error in rar e8 filter.

Vulnerable code:
  if (length > PROGRAM_WORK_SIZE || length < 4)

Fixed code:
  if (length > PROGRAM_WORK_SIZE || length <= 4)