Debian Patches

Status for xz-utils/5.4.1-1+deb12u2

Patch Description Author Forwarded Bugs Origin Last update
Translations-Add-Brazilian-Portuguese-translation-of-man-.patch Translations: Add Brazilian Portuguese translation of man pages.
Thanks to Rafael Fontenelle.		 Jia Tan <jiat0218@gmail.com> no 2023-01-27
po-pt_BR-Revert-changes-from-the-release.patch po/pt_BR: Revert changes from the release. Sebastian Andrzej Siewior <sebastian@breakpoint.cc> no 2023-01-30
Translations-Update-the-Brazilian-Portuguese-translation.patch Translations: Update the Brazilian Portuguese translation. Jia Tan <jiat0218@gmail.com> no 2023-01-13
Add-da.po-based-on-translation-from-manpages-l10n.patch Add da.po based on translation from manpages-l10n. Sebastian Andrzej Siewior <sebastian@breakpoint.cc> no 2023-02-12
liblzma-Add-assertions-to-lzma_bufcpy.patch liblzma: Add assertions to lzma_bufcpy()
(cherry picked from commit b9d168eee4fb6393b4fe207c0aeb5faee316ca1a)		 Lasse Collin <lasse.collin@tukaani.org> no 2025-04-03
liblzma-mt-dec-Fix-a-comment.patch liblzma: mt dec: Fix a comment
(cherry picked from commit 831b55b971cf579ee16a854f177c36b20d3c6999)		 Lasse Collin <lasse.collin@tukaani.org> no 2025-04-03
liblzma-mt-dec-Simplify-by-removing-the-THR_STOP-state.patch liblzma: mt dec: Simplify by removing the THR_STOP state
The main thread can directly set THR_IDLE in threads_stop() which is
called when errors are detected. threads_stop() won't return the stopped
threads to the pool or free the memory pointed by thr->in anymore, but
it doesn't matter because the existing workers won't be reused after
an error. The resources will be cleaned up when threads_end() is
called (reinitializing the decoder always calls threads_end()).

(cherry picked from commit c0c835964dfaeb2513a3c0bdb642105152fe9f34)		 Lasse Collin <lasse.collin@tukaani.org> no 2025-04-03
liblzma-mt-dec-Don-t-free-the-input-buffer-too-early-CVE-.patch liblzma: mt dec: Don't free the input buffer too early (CVE-2025-31115)

The input buffer must be valid as long as the main thread is writing
to the worker-specific input buffer. Fix it by making the worker
thread not free the buffer on errors and not return the worker thread to
the pool. The input buffer will be freed when threads_end() is called.

With invalid input, the bug could at least result in a crash. The
effects include heap use after free and writing to an address based
on the null pointer plus an offset.

The bug has been there since the first committed version of the threaded
decoder and thus affects versions from 5.3.3alpha to 5.8.0.

As the commit message in 4cce3e27f529 says, I had made significant
changes on top of Sebastian's patch. This bug was indeed introduced
by my changes; it wasn't in Sebastian's version.

Thanks to Harri K. Koskinen for discovering and reporting this issue.

(cherry picked from commit d5a2ffe41bb77b918a8c96084885d4dbe4bf6480)		 Lasse Collin <lasse.collin@tukaani.org> no 2025-04-03
liblzma-mt-dec-Don-t-modify-thr-in_size-in-the-worker-thr.patch liblzma: mt dec: Don't modify thr->in_size in the worker thread
Don't set thr->in_size = 0 when returning the thread to the stack of
available threads. Not only is it useless, but the main thread may
read the value in SEQ_BLOCK_THR_RUN. With valid inputs, it made
no difference if the main thread saw the original value or 0. With
invalid inputs (when worker thread stops early), thr->in_size was
no longer modified after the previous commit with the security fix
("Don't free the input buffer too early").

So while the bug appears harmless now, it's important to fix it because
the variable was being modified without proper locking. It's trivial
to fix because there is no need to change the value. Only main thread
needs to set the value in (in SEQ_BLOCK_THR_INIT) when starting a new
Block before the worker thread is activated.

(cherry picked from commit 8188048854e8d11071b8a50d093c74f4c030acc9)		 Lasse Collin <lasse.collin@tukaani.org> no 2025-04-03
liblzma-Fix-a-buffer-overflow-in-lzma_index_append.patch liblzma: Fix a buffer overflow in lzma_index_append()
If lzma_index_decoder() was used to decode an Index that contained no
Records, the resulting lzma_index had an invalid internal "prealloc"
value. If lzma_index_append() was called on this lzma_index, too
little memory would be allocated and a buffer overflow would occur.

While this combination of the API functions is meant to work, in the
real-world apps this call sequence is rare or might not exist at all.

This bug is older than xz 5.0.0, so all stable releases are affected.

(cherry picked from commit c8c22869e780ff57c96b46939c3d79ff99395f87)
(cherry picked from commit 8538443d08591693a8c61f3a03656650f39c7c32)		 Lasse Collin <lasse.collin@tukaani.org> no https://github.com/tukaani-project/xz/commit/8538443d08591693a8c61f3a03656650f39c7c32 2026-03-29
xz-Prevent-an-integer-overflow-in-files-and-files0.patch xz: Prevent an integer overflow in --files and --files0
This requires a filename (or something that pretends to be a filename)
of at least 2 GiB on a 32-bit platform, and that realloc() to
SIZE_MAX / 2 + 1 bytes has succeeded.

(cherry picked from commit 0ac3b93387c0191919ffa38de5f49f6b28164b35)
(cherry picked from commit 32e80eb55e2a291be551ab5742755406d099fe67)		 Lasse Collin <lasse.collin@tukaani.org> no https://github.com/tukaani-project/xz/commit/32e80eb55e2a291be551ab5742755406d099fe67 2026-03-25
liblzma-mt-dec-Protect-progress_in-update-with-mutex.patch liblzma: mt dec: Protect progress_in update with mutex
Worker threads update coder->progress_in while holding coder->mutex, but
the main thread updated the same field without the mutex while decoding
the next Block Header. ThreadSanitizer reported the concurrent writes and
lzma_get_progress() under-reported input progress by one Block.

All other coder->progress_in/progress_out accesses in stream_decode_mt()
are done when the worker threads aren't active, so only the access in
SEQ_BLOCK_HEADER needs to lock coder->mutex.

(cherry picked from commit c6e3aadbb510e44cecfe870408ecfea1d1ca792c)
(cherry picked from commit 113a24a2bb67a601ea84696b86c557d501ee8ada)		 Trithem90 <149891156+Trithem90@users.noreply.github.com> no 2026-09-03
liblzma-Make-lzma_lz_decoder_init-safe-to-reinit-after-al.patch liblzma: Make lzma_lz_decoder_init() safe to reinit after alloc failure

If memory allocation fails and the resulting coder state is reused,
ensure that memory allocation is attempted again. However, coders that
are initialized via lzma_next_filter_init() shouldn't be reinitialized
after failure; they should be cleaned up with lzma_next_end().

(cherry picked from commit fe4d763d566a38ad61d4c5022520c25578a3a464)
(cherry picked from commit 4c5accf7206a4580a7d3b095d40db04e4bbbff63)		 Lasse Collin <lasse.collin@tukaani.org> no 2026-09-09
liblzma-Clean-up-after-a-filter-chain-initialization-erro.patch liblzma: Clean up after a filter chain initialization error
Filter coders are initialized using lzma_next_filter_init(). If filter
chain initialization fails, the entire filter chain should be cleaned up
with lzma_next_end(). lzma_raw_encoder_init() and lzma_raw_decoder_init()
have always done this via lzma_raw_coder_init() in filter_common.c.
(Separate cleanup is weird, but it must have made sense to the young me.)

The following decoders initialize LZMA1 filter directly without using the
raw filter chain API. This avoids needlessly pulling in all other filters
when a program is linked against static liblzma. These functions didn't
call lzma_next_end() after an initialization error, which left the state
available for later reinitialization.

- lzma_alone_decoder()
- lzma_lzip_decoder()
- lzma_auto_decoder() [*]
- lzma_microlzma_decoder()

[*] lzma_auto_decoder() is only indirectly affected due to the first two
functions. lzma_auto_decoder() itself doesn't need a fix.

There are also encoder functions that initialize the LZMA1 encoder
directly. They don't have this issue because the whole lzma_stream
is cleaned up when encoder initialization fails.

(cherry picked from commit e5e63d50eac1b4357a5a7a0abd3c5f99a5c47881)
(cherry picked from commit 05af863c3166cddeb4ab935829b14e995c8346b4)		 Lasse Collin <lasse.collin@tukaani.org> no 2026-09-09

All known versions for source package 'xz-utils'

Links