-------------------- Start of forwarded message -------------------- Date: Wed, 9 Sep 2026 19:53:10 +0300 From: Lasse Collin <lasse.collin () tukaani org> To: xz-devel () tukaani org Subject: XZ Utils 5.8.4 and a security fix

XZ Utils 5.8.4 is available at <https://tukaani.org/xz/#stable>.

In XZ Utils 5.8.3 and older, an invalid memory write can occur if a decoder is reinitialized after allocation failure. For details, see the security advisory:

https://tukaani.org/xz/invalid-write-after-reinit.html

This and a few other fixes have also been committed to the old stable branches (v5.2, v5.4, and v5.6) in the xz Git repository. Those fixes are marked below. No new 5.2.x, 5.4.x, or 5.6.x releases will be made.

5.8.4 (2026-09-09)

liblzma:

- lzmaalonedecoder(), lzmalzipdecoder(), lzmaautodecoder(), and lzmamicrolzmadecoder(): Fix an invalid memory access after memory allocation has failed and the application reinitializes the existing decoder to decode a different file. This bug could at least result in a crash. This is tracked as GHSA-5qpq-xqfv-j9pg. CVE number is pending. (Also in v5.2, v5.4, and v5.6.)

- lzmastreambufferdecode(): Fix wrong error code and, in debug builds, assertion failure. LZMABUFERROR could be returned with truncated inputs while LZMADATAERROR is the correct one in this function. (Also in v5.2, v5.4, and v5.6.)

- Fix a performance issue in the typical use case of lzmaindexcat(). Internally liblzma calls it from lzmafileinfodecoder(), so that was affected too. The problem occurred if the input .xz file was created by concatenating a large number of .xz files. A crafted file could make "xz --list" very slow or effectively hang. Normal decompression doesn't use these functions and thus wasn't affected. (Also in v5.2, v5.4, and v5.6.)

- Fix a theoretical integer overflow in lzmaindexcat(). (Also in v5.2, v5.4, and v5.6.)

- Fix bogus memory usage report in lzmaindexdecoder() when the .xz Index is obviously invalid. A huge bogus value could cause an integer overflow in lzmafileinfodecoder()'s memory usage reporting due to a missing overflow check, making lzmamemused() report an incorrect tiny value. This bug didn't affect the memory usage limiter in these two decoders; only the reporting via lzmamemused() was affected. (Also in v5.2, v5.4, and v5.6.)

- Fix a too low memory usage report in lzmaindexdecoder() if lzmamemused() is called after a part of the Index has already been decoded. The typical use case is to call lzmamemused() immediately after LZMAMEMLIMITERROR, which did work correctly.

- Fix copying of check type in lzmaindexdup(). Calling lzmaindexchecks() on the duplicated lzmaindex returned return garbage a result. lzmaindexdup() is rarely used; liblzma doesn't use it internally and xz itself doesn't use it either. (Also in v5.2, v5.4, and v5.6.)

- lzmafileinfodecoder() and lzmaindexdecoder(): Reject an obviously-invalid Number of Records field earlier. (Partially also in v5.2, v5.4, and v5.6.)

- Fix a missing synchronization in the threaded .xz decoder. It could make lzmagetprogress() return incorrect progress info. (Also in v5.4 and v5.6.)

- Detect certain kinds of corrupt inputs slightly earlier in the LZMA2 decoder.

- ARM64 and LoongArch: Don't use aligned reads on unaligned buffers. This makes the code work on strict-align processors and fixes a sanitizer error in other cases. (Since 5.7.1alpha)

xz:

- Fix a use-after-free when showing an error message if --files or --files0 was specified in the environment variables XZOPT or XZDEFAULTS. (Also in v5.2, v5.4, and v5.6.)

- Fix a use-after-free bug when --verbose is used and standard error isn't a terminal. (Since 5.7.1alpha)

- Make it an error if the totals in "xz --list" exceed the range of 64-bit integers. (Also in v5.2, v5.4, and v5.6.)

xz and xzdec on Linux:

- Add support for Landlock ABI version 9.

- Use fallback macros for Landlock ABI version 2, 3, and 5 (but not 4) if <linux/landlock.h> is older than ABI version 5. This makes the binary slightly more protected if it is run on a kernel that supports newer ABIs than <linux/landlock.h>.

Scripts:

- xzgrep: Fix handling of the ' char at the end of a command line option. For example, the following tricked xzgrep to run "id": xzgrep "-e'" "-e;id;'" somefile (Also in v5.2, v5.4, and v5.6.)

- xzdiff: Use the C locale (LCALL=C) with "sed" and "expr" to ensure safe behavior with invalid multibyte sequences. An equivalent improvement was made in xzgrep in 5.2.6 (2022-08-12), but it was forgotten from xzdiff. (Also in v5.2, v5.4, and v5.6.)

Tests:

- Improve a few tests and fuzz targets.

- Add new test files: bad-0-index-1.xz (32 bytes) bad-1-index-huge-uncomp.xz (72 bytes)

Man pages:

- Improve the rendering with OpenBSD's mandoc(1).

- Reduce indentation of the tables to avoid overlong lines in translated versions of the xz man page.

Translations:

- In translated man pages, workaround an issue with non-ASCII characters in tables.

- Fix syntax errors in a few man page translations.

- Update Arabic and German man page translations.

- Update Brazilian Portuguese, Croatian, Dutch, German, Italian, Korean, Polish, Portuguese, Romanian, and Ukrainian message translations.

-- Lasse Collin

-------------------- End of forwarded message --------------------

Hi,

We've released a new xz version with some minor security fixes. It's not believed that any application is actually vulnerable to the main one, nor the other. It requires an unusual use of a rarely called API.

-------------------- Start of forwarded message -------------------- Date: Tue, 31 Mar 2026 19:58:29 +0300 From: Lasse Collin <lasse.collin () tukaani org> To: xz-announce () tukaani org Subject: XZ Utils 5.8.3 and a security fix

In XZ Utils 5.8.2 and older, a buffer overflow can occur in lzmaindexappend() under conditions that likely don't exist in any real-world application (CVE-2026-34743). No new 5.2.x, 5.4.x, or 5.6.x releases will be made, but the fix is in the v5.2, v5.4, and v5.6 branches in the xz Git repository. For details, see the NEWS entry below or the security advisory:

https://tukaani.org/xz/index-append-overflow.html

XZ Utils 5.8.3 is available at <https://tukaani.org/xz/#stable>.

5.8.3 (2026-03-31)

liblzma:

- Fix a buffer overflow in lzmaindexappend(): If lzmaindexdecoder() was used to decode an Index that contained no Records, the resulting lzmaindex was left in a state where where a subsequent lzmaindexappend() would allocate too little memory, and a buffer overflow would occur.

The lzmaindex functions are rarely used by applications directly. In the few applications that do use these functions, the combination of function calls required to trigger this bug are unlikely to exist, because there typically is no reason to append Records to a decoded lzmaindex. Thus, it's likely that this bug cannot be triggered in any real-world application.

The bug was reported and discovered by Cantina using their AppSec agent, Apex.

- Fix the build on Windows ARM64EC.

- Add "License: 0BSD" to liblzma.pc.

xz:

- Fix invalid memory access in --files and --files0. All of the following must be true to trigger it:

1. A string being read (which supposedly is a filename) is at least SIZEMAX / 2 bytes long. This size is plausible on 32-bit platforms (2 GiB - 1 B).

2. realloc(ptr, SIZEMAX / 2 + 1) must succeed. On glibc >= 2.30 it shouldn't because the value exceeds PTRDIFFMAX.

3. An integer overflow results in a realloc(ptr, 0) call. If it doesn't return NULL, then invalid memory access will occur.

- On QNX, don't use fsync() on directories because it fails.

Autotools: Enable 32-bit x86 assembler on Hurd by default. It was already enabled in the CMake-based build.

Translations: Add Arabic man page translations.

-- Lasse Collin

-------------------- End of forwarded message --------------------

An arbitrary file write vulnerability was found in GNU gzip's zgrep utility. When zgrep is applied on the attacker's chosen file name (for example, a crafted file name), this can overwrite an attacker's content to an arbitrary attacker-selected file. This flaw occurs due to insufficient validation when processing filenames with two or more newlines where selected content and the target file names are embedded in crafted multi-line file names. This flaw allows a remote, low privileged attacker to force zgrep to write arbitrary files on the system.