Last updated 2 June 2026

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

Hi!

An issue has been found in xz. I emphasise that it's not an issue related to the nasty events of last year, and it wasn't introduced by Jia. Nonetheless, it's a bug with some security impact.

This was privately communicated to the private distros ML on 2025-03-31.

We have attached patches which will be part of 5.8.1 and should apply cleanly to the affected versions.

The CVE for this issue, allocated by GitHub is CVE-2025-31115. I'm sending this on behalf of Lasse Collin (cc'd).

..

Advisory link: https://tukaani.org/xz/threaded-decoder-early-free.html GitHub advisory link: https://github.com/tukaani-project/xz/security/advisories/GHSA-6cc8-p5mm-29w2

Impact

The threaded .xz decoder in liblzma has a bug that can at least result in a crash (denial of service). The effects include heap use after free and writing to an address based on the null pointer plus an offset.

This affects XZ Utils versions from 5.3.3alpha to 5.8.0. Applications and libraries that use the lzmastreamdecodermt function are affected.

Patches

The bug has been fixed in XZ Utils 5.8.1, and the fix has been committed to the v5.4, v5.6, v5.8, and master branches in the xz Git repository. No new release packages will be made from the old stable branches, but a standalone patch is available that applies to all affected releases (attached to this email).

For convenience, links are below for...

5.4: https://github.com/tukaani-project/xz/commit/77bc2d6f3b6e1506c122b03cff49c902219869e3 https://github.com/tukaani-project/xz/commit/bdb788137e1f1d967e0c9d885b859e5b95c1b5bf https://github.com/tukaani-project/xz/commit/2ce9ab6588a94cbf04a9c174e562ea5feb00cfb3 https://github.com/tukaani-project/xz/commit/9a9c17712bd2a070581d9239692e527a2fe13845 https://github.com/tukaani-project/xz/commit/c8bb46c5a16ed02401f4a0b46c74f0f46c1b6434

5.6: https://github.com/tukaani-project/xz/commit/fb1210f215d61bd3ea373d61e4d86d29648e1bab https://github.com/tukaani-project/xz/commit/c1a91b8baeb947c5b232a6c3d6319267131830bc https://github.com/tukaani-project/xz/commit/f74cf18ad084a9185d8ae148d89265860aa8004c https://github.com/tukaani-project/xz/commit/1b874b4f04909b7bb5259cb612ecef39a434dde8 https://github.com/tukaani-project/xz/commit/6ff5b8c55960f9ebc917b668bd3567ef217175fa

5.8: https://github.com/tukaani-project/xz/commit/b9d168eee4fb6393b4fe207c0aeb5faee316ca1a https://github.com/tukaani-project/xz/commit/831b55b971cf579ee16a854f177c36b20d3c6999 https://github.com/tukaani-project/xz/commit/c0c835964dfaeb2513a3c0bdb642105152fe9f34 https://github.com/tukaani-project/xz/commit/d5a2ffe41bb77b918a8c96084885d4dbe4bf6480 https://github.com/tukaani-project/xz/commit/8188048854e8d11071b8a50d093c74f4c030acc9

and xz-5.8.1 has just been released.

Workarounds

The single-threaded .xz decoder (lzmastreamdecoder) isn't affected. The commands xz --decompress --threads=1 and xzdec use the single-threaded decoder.

Credits

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

Thanks to Sebastian Andrzej Siewior for reviewing the patches.

Thanks to Sam James for general help.

Why fuzzing didn't find this?

XZ Utils is fuzzed by OSS-Fuzz. However, there was no program to fuzz the multithreaded .xz decoder. Even if there had been, it likely would have used the fuzzcode function in fuzzcommon.h like the existing fuzz targets did. That function called lzmacode in such a way that it would have been impossible to trigger this bug.

Lasse Collin has been working on improving the fuzzer and with some changes, we've been able to make it detect the bug.

See https://github.com/tukaani-project/xz/commit/48440e24a25911ae59e8518b67a1e0f6f1c293bf and https://github.com/tukaani-project/xz/commit/513cabcf7f5ce1c3ed0619e791393fc53d1dbbd0 for that.

Here is the fourth Landlock newsletter!

Official website: https://landlock.io Previews newsletter: https://lore.kernel.org/landlock/d4ed5733-d07b-5548-2534-a63e22906778 () digikod net

Articles and conferences ------------------------

We wrote a detailed article about Landlock explaining the underlying concepts, the implementation, and the community: https://landlock.io/talks/2024-06-06landlock-article.pdf This was written for the SSTIC conference: https://www.sstic.org/2024/presentation/landlock-design/

I did a workshop at the Pass the Salt conference to explain how to mitigate security vulnerabilities with Landlock (demonstrated with ImageMagick): https://cfp.pass-the-salt.org/pts2024/talk/8FVYDF/ Related materials are freely available to do it at home: https://github.com/landlock-lsm/workshop-imagemagick

Arto Niemi published a "Survey of Real-World Process Sandboxing" at the Conference of Open Innovations Association (FRUCT): https://fruct.org/publications/volume-35/fruct35/files/Niem.pdf Their conclusion: "[...] we found Landlock and minijail [which uses Landlock] to be relatively convenient from a developer perspective. In general, process self-containment and process-wrapping seems to be an order of magnitude easier to configure than MAC policies."

Researchers from University of Bergamo gave a talk at ASIA CCS conference about Cage4Deno: A Fine-Grained Sandbox for Deno Subprocesses (leveraging Landlock) https://cs.unibg.it/seclab-papers/2023/ASIACCS/paper/cage4deno.pdf They also gave a talk at the RAID conference about NatiSand: Native Code Sandboxing for JavaScript Runtimes (leveraging Landlock) https://cs.unibg.it/seclab-papers/2023/RAID/natisand.pdf

Eric Leblond gave a talk (in French) at the SSTIC conference about sandboxing with Landlock to mitigate real world security issues: https://www.sstic.org/2023/presentation/attaquesupplychainsuricata/

Günther Noack will give a talk at LSS Europe about Landlock and the new IOCTL support: https://sched.co/1ebVW

I'll give a talk at OSS Europe to better explain sandboxing with Landlock: https://sched.co/1ej3a

The XZ backdoor ---------------

XZ Utils is a widely used compression tool and library. The main maintainer implemented sandboxing with Landlock, and released a new version 5.6.0 with this feature. In March 2024, a backdoor was found and reported. It was introduced in February by a new maintainer who earned this trust after more than two years of effort.

Among the malicious changes, the attacker disabled Landlock's support for XZ Utils and released a new version 5.6.1: https://research.swtch.com/xz-timeline The sabotaged configuration check has since been fixed with version 5.6.2, but this effort to stealthily disable sandboxing is a clear sign that Landlock disturbs attackers: https://github.com/tukaani-project/xz/commit/f9cf4c05edd1

Merged kernel features ----------------------

Linux 6.7 (Landlock ABI 4) supports initial network access control with the LANDLOCKACCESSNETBINDTCP and LANDLOCKACCESSNETCONNECTTCP rights thanks to Konstantin Meskhidze. We can now control inbound and outbound TCP connections according to the source or the destination port. This led to kernel code refactoring which opens the way to more network protocol support. See user space documentation: https://docs.kernel.org/userspace-api/landlock.html#network-flags

Linux 6.10 (Landlock ABI 5) supports IOCTL control with the new LANDLOCKACCESSFSIOCTLDEV right thanks to Günther Noack. This restriction only applies to IOCTL commands implemented by device drivers (i.e. block or character devices). As other file system access rights, this can be used to only allow such IOCTL commands on a specified set of file hierarchies per sandbox. See user space documentation: https://docs.kernel.org/userspace-api/landlock.html#filesystem-flags

We also added a slight change in all supported kernels to inform system administrators (with kernel logs) how they can configure the system to support Landlock, if a process tried to sandbox itself on a kernel where Landlock is disabled. New documentation will help enable Landlock on systems when it is not already the case: https://docs.kernel.org/userspace-api/landlock.html#kernel-support

Since Linux 6.3, we improved documentation and kselftests (user space testing), and added support for KUnit (kernel testing). Part of this work lead us to support the UML architecture to easily run application tests in a CI against different kernel versions. With this support we can make sure that backward compatibility works fine for the tested applications. I encourage to take a look at landlock-test-tools and the GitHub CI configuration for the Rust library: https://github.com/landlock-lsm/landlock-test-tools https://github.com/landlock-lsm/rust-landlock/blob/main/.github/workflows/rust.yml#L166-L179

Roadmap and ongoing development -------------------------------

We created GitHub issues to track ongoing and future work: https://github.com/landlock-lsm/linux/issues https://github.com/orgs/landlock-lsm/projects/1

Feel free to reach out if you want to contribute! https://github.com/landlock-lsm/linux/contribute

We also plan to improve the website with extended documentation and examples.

Kernel development highlights -----------------------------

Günther Noack is now an official reviewer of Landlock! https://git.kernel.org/torvalds/c/5bf9e57e634b After the IOCTL feature, he is now working on improving the documentation, including man pages.

Mikhail Ivanov is working on socket type control. This is an important feature that will make it possible to create sandboxes without any network access, except for an explicit list of allowed protocols. This will nicely complement the TCP port control (and future ones for other protocols): https://github.com/landlock-lsm/linux/issues/6 He is also working on controlling TCP listen calls: https://github.com/landlock-lsm/linux/issues/15

Tahera Fahimi was selected as an Outreachy intern to work on IPC restrictions (e.g. abstract unix socket, signals) to better isolate a Landlock domain: https://github.com/landlock-lsm/linux/issues/7 https://github.com/landlock-lsm/linux/issues/8

I'm working on bringing audit support to Landlock: https://github.com/landlock-lsm/linux/issues/3

Landlock libraries ------------------

As explained by Günther Noack, the Go library now supports TCP and IOCTL restrictions: https://blog.gnoack.org/post/landlock-v4/ https://blog.gnoack.org/post/landlock-ioctl/

A new version of the Rust crate was released, with support for TCP control and some miscellaneous improvements: https://github.com/landlock-lsm/rust-landlock/releases/tag/v0.4.0

Please update your dependencies and use the latest Landlock ABI version for improved sandboxing.

We are also working on a new minimal C library: https://github.com/landlock-lsm/linux/issues/38

New Landlock user space supports --------------------------------

Firejail 0.9.74 (sandboxer) will be able to use landlock: https://github.com/netblue30/firejail/pull/6078

setpriv 2.40 (sandboxer): https://github.com/util-linux/util-linux/pull/2628

extrasafe 0.4.0 (sandbox library): https://github.com/boustrophedon/extrasafe/pull/28

bevymodlockdown (sandbox library): https://github.com/FrTerstappen/bevymodlockdown

Cloud Hypervisor (VM monitor) will be sandboxed with Landlock: https://github.com/cloud-hypervisor/cloud-hypervisor/pull/6214

Ukuleleweb (wiki server): https://github.com/gnoack/ukuleleweb/commit/0ecdd54b36fa

websrv 3.2.0 (web server): https://github.com/ngergs/websrv/commit/40fa2d7d2bbb

egress-eddie 0.5.0 (network filtering): https://github.com/capnspacehook/egress-eddie/releases/tag/v0.5.0

Suricata 7.0.0 (network security monitoring engine): https://docs.suricata.io/en/latest/configuration/landlock.html

sslh 2.1.0 (protocol multiplexer): https://lore.kernel.org/landlock/Zfq6f30spnYCx9Y () rutschle net/ https://github.com/yrutschle/sslh/releases/tag/v2.1.0

wireproxy 1.0.8 (Wireguard client): https://github.com/pufferffish/wireproxy/pull/108

Emilua 0.5.0 (Lua runtime): https://lore.kernel.org/landlock/CAK9RveLxro4zUG4jfFB=UNgcv5gdc8JuzNhMt=YbNhH=35ADzg () mail gmail com/ https://docs.emilua.org/api/0.5/changelog.html

Polkadot (blockchain SDK): https://github.com/paritytech/polkadot/pull/7303

XZ Utils 5.6.2 (archive manager): https://github.com/tukaani-project/xz/commit/374868d81d47

Zathura (document viewer) will be sandboxed with Landlock: https://github.com/pwmt/zathura/pull/575

Pacman 7.0.0 (Arch Linux's package manager): https://gitlab.archlinux.org/pacman/pacman/-/mergerequests/167

Thanks to all contributors!

Regards, Mickaël

Last updated 4 August 2025

An issue discovered in XZ 5.2.5 allows attackers to cause a denial of service via decompression of crafted file.

References:

https://tukaani.org/xz/ https://github.com/snappyJack/CVE-request-XZ-5.2.5-has-denial-of-service-vulnerability

DISPUTED An issue discovered in XZ 5.2.5 allows attackers to cause a denial of service via decompression of a crafted file. NOTE: the vendor disputes the claims of "endless output" and "denial of service" because decompression of the 17,486 bytes always results in 114,881,179 bytes, which is often a reasonable size increase.

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.

It was found that xzgrep did not correctly process file names containing a semicolon. A local attacker able to trick a user to run xzgrep on a specially crafted file could use this flaw to execute arbitrary code as the user running xzgrep.

$ touch /tmp/semi\;colon $ xzgrep anystring /tmp/semi\;colon xz: /tmp/semi: No such file or directory /usr/bin/xzgrep: line 199: colon: command not found

Additional details:

http://seclists.org/oss-sec/2015/q2/484