Debian Patches

Status for libarchive/3.6.2-1+deb12u3

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 [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 [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 [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

All known versions for source package 'libarchive'

Links