Debian Patches

Status for libarchive/3.6.2-1+deb12u4

Patch Description Author Forwarded Bugs Origin Last update
typos.patch Correct some typographical errors. Peter Pentchev <roam@ringlet.net> yes 2022-03-29
iconv-pkgconfig.patch Do not add "iconv" to pkg-config unless it is needed Peter Pentchev <roam@ringlet.net> yes 2022-12-24
robust-error-reporting.patch tar: make error reporting more robust and use correct errno Ed Maste <emaste@freebsd.org> no upstream, https://github.com/libarchive/libarchive/commit/6110e9c82d8ba830c3440f36b990483ceaaea52c 2024-03-30
fix-OOB-in-rar-e8-filter-2135.patch fix: OOB in rar e8 filter (#2135)
This patch fixes an out-of-bound error in rar e8 filter.		 Wei-Cheng Pan <legnaleurc@gmail.com> yes debian upstream https://github.com/libarchive/libarchive/commit/eb7939b24a681a04648a59cdebd386b1e9dc9237 2024-04-22
fix-OOB-in-rar-delta-filter-2148.patch fix: OOB in rar delta filter (#2148)
Ensure that `src` won't move ahead of `dst`, so `src` will not OOB.
Since `dst` won't move in this function, and we are only increasing `src`
position, this check should be enough. It should be safe to early return
because this function does not allocate resources.		 Wei-Cheng Pan <legnaleurc@gmail.com> no https://github.com/libarchive/libarchive/commit/a1cb648d52f5b6d3f31184d9b6a7cbca628459b7 2024-04-29
fix-OOB-in-rar-audio-filter-2149.patch fix: OOB in rar audio filter (#2149)
This patch ensures that `src` won't move ahead of `dst`, so `src` will
not OOB. Similar situation like in a1cb648.		 Wei-Cheng Pan <legnaleurc@gmail.com> no https://github.com/libarchive/libarchive/commit/3006bc5d02ad3ae3c4f9274f60c1f9d2d834734b 2024-04-29
rar4-reader-protect-copy_from_lzss_window_to_unp-217.patch rar4 reader: protect copy_from_lzss_window_to_unp() (#2172)
copy_from_lzss_window_to_unp unnecessarily took an `int` parameter where
both of its callers were holding a `size_t`.

A lzss opcode chain could be constructed that resulted in a negative
copy length, which when passed into memcpy would result in a very, very
large positive number.

Switching copy_from_lzss_window_to_unp to take a `size_t` allows it to
properly bounds-check length.

In addition, this patch also ensures that `length` is not itself larger
than the destination buffer.		 "Dustin L. Howett" <dustin@howett.net> yes debian upstream https://github.com/libarchive/libarchive/commit/eac15e252010c1189a5c0f461364dbe2cd2a68b1 2024-05-09
CVE-2025-5914.patch rar: Fix double free with over 4 billion nodes
If a system is capable of handling 4 billion nodes in memory, a double
free could occur because of an unsigned integer overflow leading to a
realloc call with size argument of 0. Eventually, the client will
release that memory again, triggering a double free.		 Tobias Stoeckmann <tobias@stoeckmann.org> no 2025-05-10
CVE-2025-5915.patch [PATCH 1/4] A test case for Issue #2565.
This just takes the PoC from that issue and wraps
it into a standard test.
I've not yet used this to reproduce the issue, much
less to diagnose the root cause.		 Tim Kientzle <kientzle@acm.org> no 2025-04-06
CVE-2025-5916.patch warc: Prevent signed integer overflow
If a warc archive claims to have more than INT64_MAX - 4 content bytes,
the inevitable failure to skip all these bytes could lead to parsing
data which should be ignored instead.

The test case contains a conversation entry with that many bytes and
if the entry is not properly skipped, the warc implementation would read
the conversation data as a new file entry.		 Tobias Stoeckmann <tobias@stoeckmann.org> no 2025-04-06
CVE-2025-5917.patch Fix overflow in build_ustar_entry
The calculations for the suffix and prefix can increment the endpoint for a
trailing slash. Hence the limits used should be one lower than the
maximum number of bytes.		 Brian Campbell <Brian.Campbell@ed.ac.uk> no 2025-04-24
CVE-2025-5918-pre1.patch Improve lseek handling (#2564)
The skip functions are limited to 1 GB for cases in which libarchive
runs on a system with an off_t or long with 32 bits. This has negative
impact on 64 bit systems.

Instead, make sure that _all_ subsequent functions truncate properly.
Some of them already did and some had regressions for over 10 years.

Tests pass on Debian 12 i686 configured with --disable-largefile, i.e.
running with an off_t with 32 bits.

Casts added where needed to still pass MSVC builds.		 Tobias Stoeckmann <stoeckmann@users.noreply.github.com> no 2025-04-06
CVE-2025-5918_1.patch Do not skip past EOF while reading (#2584)
Make sure to not skip past end of file for better error messages. One
such example is now visible with rar testsuite. You can see the
difference already by an actually not useless use of cat:

```
$ cat .../test_read_format_rar_ppmd_use_after_free.rar | bsdtar -t
```

compared to

```
$ bsdtar -tf .../test_read_format_rar_ppmd_use_after_free.rar
```

Since the former cannot lseek, the error is a different one
(ARCHIVE_FATAL vs ARCHIVE_EOF). The piped version states explicitly that
truncation occurred, while the latter states EOF because the skip past
the end of file was successful.

(cherry picked from commit dcbf1e0ededa95849f098d154a25876ed5754bcf)		 Tobias Stoeckmann <stoeckmann@users.noreply.github.com> no https://github.com/libarchive/libarchive/commit/dcbf1e0ededa95849f098d154a25876ed5754bcf 2025-04-15
CVE-2025-5918_2.patch Fix FILE_skip regression
The fseek* family of functions return 0 on success, not the new offset.
This is only true for lseek.

Fixes https://github.com/libarchive/libarchive/issues/2641
Fixes dcbf1e0ededa95849f098d154a25876ed5754bcf		 Tobias Stoeckmann <tobias@stoeckmann.org> no https://github.com/libarchive/libarchive/commit/51b4c35bb38b7df4af24de7f103863dd79129b01 2025-05-27
CVE-2026-4111-1.patch Infinite loop in Rar5 decompression
Found by: Elhanan Haenel		 Tim Kientzle <kientzle@acm.org> no backport, https://github.com/libarchive/libarchive/commit/ef53e2023d75a205cf7cbddb5d01c4cc592e9ce4 2026-03-01
CVE-2026-4111-2.patch Reject filters when the block length is nonsensical Tim Kientzle <kientzle@acm.org> no upstream, https://github.com/libarchive/libarchive/commit/7273d04803a1e5a482f26d8d0fbaf2b204a72168 2026-03-01
CVE-2026-4424-1.patch rar: fix LZSS window size mismatch after PPMd block
When a PPMd-compressed block updates dictionary_size, the LZSS window
from a prior block is not reallocated. The allocation guard only checks
if dictionary_size is zero or the window pointer is NULL, not whether
the existing window is large enough. This allows copy_from_lzss_window()
to read past the allocated buffer.

Fix the guard to also check whether the current window is undersized.
Add bounds checks in copy_from_lzss_window() and parse_filter() as
defense in depth.		 elhananhaenel <elhanan.haenel@mail.huji.ac.il> no upstream, https://github.com/libarchive/libarchive/commit/d379dc0b2976b7207d1ad78f5ed3eb99a5b6d375 2026-03-07
CVE-2026-4424-2.patch Fix -Wsign-compare: cast mask+1 to unsigned int elhananhaenel <elhanan.haenel@mail.huji.ac.il> no upstream, https://github.com/libarchive/libarchive/commit/e1907c5832b6489c7b4198b0825f857c93a03c10 2026-03-08
CVE-2026-4426_CVE-2026-5121.patch Add regression test for zisofs 32-bit heap overflow
A crafted ISO with pz_log2_bs=2 and pz_uncompressed_size=0xFFFFFFF9
causes an integer overflow in the block pointer allocation in
zisofs_read_data(). On 32-bit, (ceil+1)*4 wraps size_t to 0, malloc(0)
returns a tiny buffer, and the code writes ~4GB past it.

The pz_log2_bs validation fix prevents this. Add a regression test with
a crafted 48KB ISO that triggers the overflow on unfixed 32-bit builds.		 elhananhaenel <elhanan.haenel@mail.huji.ac.il> no upstream, https://github.com/libarchive/libarchive/commit/a2a73a8f14b3208c7f6acbbc93265254a7c1efd0 2026-03-19

All known versions for source package 'libarchive'

Links