Debian Patches

Status for libarchive/3.7.4-4+deb13u1

Patch Description Author Forwarded Bugs Origin Last update
typos.patch Correct some typographical errors. Peter Pentchev <roam@ringlet.net> yes 2022-03-29
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-1632-25724.patch fix CVE-2025-1632 and CVE-2025-25724 Peter Kästle <peter@piie.net> no upstream, https://github.com/libarchive/libarchive/commit/c9bc934e7e91d302e0feca6e713ccc38d6d01532 2025-04-27
CVE-2025-5914.patch rar: Fix double free with over 4 billion nodes (#2598) 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 debian upstream, https://github.com/libarchive/libarchive/commit/09685126fcec664e2b8ca595e1fc371bd494d209 2025-07-24
CVE-2025-5915.patch rar: Fix heap-buffer-overflow (#2599) A filter block size must not be larger than the lzss window, which is
defined
by dictionary size, which in turn can be derived from unpacked file
size.
.
While at it, improve error messages and fix lzss window wrap around
logic.
.
Fixes https://github.com/libarchive/libarchive/issues/2565		 Tobias Stoeckmann <tobias@stoeckmann.org> no debian upstream, https://github.com/libarchive/libarchive/commit/a612bf62f86a6faa47bd57c52b94849f0a404d8c 2025-07-24
CVE-2025-5916.patch warc: Prevent signed integer overflow (#2568) 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 debian upstream, https://github.com/libarchive/libarchive/commit/ef093729521fcf73fa4007d5ae77adfe4df42403 2025-07-24
CVE-2025-5917.patch Fix overflow in build_ustar_entry (#2588) 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.
.
Without this patch, when this happens for both the prefix and the
suffix, we end up with 156 + 100 bytes, and the write of the null at the
end will overflow the 256 byte buffer. This can be reproduced by running
```
mkdir -p foo/bar
bsdtar cvf test.tar foo////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////bar
```
when bsdtar is compiled with Address Sanitiser, although I originally
noticed this by accident with a genuine filename on a CHERI capability
system, which faults immediately on the buffer overflow.		 Brian Campbell <Brian.Campbell@ed.ac.uk> no debian upstream, https://github.com/libarchive/libarchive/commit/7c02cde37a63580cd1859183fbbd2cf04a89be85 2025-07-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