Debian Patches

Status for xz-utils/5.8.1-1+deb13u2

Patch Description Author Forwarded Bugs Origin Last update
0001-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.		 Lasse Collin <lasse.collin@tukaani.org> no 2026-03-29
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)		 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)		 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)		 Lasse Collin <lasse.collin@tukaani.org> no 2026-09-09
liblzma-Make-lzma_simple_coder_init-reinit-safe-after-all.patch liblzma: Make lzma_simple_coder_init() reinit-safe after alloc failure

lzma_raw_coder_init() always calls lzma_next_end() if an error occurs
in filter initialization, and no other code path can call
lzma_simple_coder_init(), so this change doesn't fix any bug.
This is just to reduce likelyhood of future bugs.

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

All known versions for source package 'xz-utils'

Links