Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1270974 > unrolled thread

Bug#1121085: Landlock: Workaround a bug in RHEL 9 kernel

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1121085: Landlock: Workaround a bug in RHEL 9 kernel Philipp Matthias Hahn <pmhahn@debian.org> - 2025-11-20 20:20 +0100
    Bug#1121085: Landlock: Workaround a bug in RHEL 9 kernel Lasse Collin <lasse.collin@tukaani.org> - 2025-11-21 20:00 +0100
      Bug#1121085: Landlock: Workaround a bug in RHEL 9 kernel Lasse Collin <lasse.collin@tukaani.org> - 2025-11-23 21:10 +0100
        Bug#1121085: Landlock: Workaround a bug in RHEL 9 kernel Sebastian Andrzej Siewior <sebastian@breakpoint.cc> - 2025-11-23 21:50 +0100
          Bug#1121085: Landlock: Workaround a bug in RHEL 9 kernel Lasse Collin <lasse.collin@tukaani.org> - 2025-11-23 22:00 +0100
            Bug#1121085: Landlock: Workaround a bug in RHEL 9 kernel Sebastian Andrzej Siewior <sebastian@breakpoint.cc> - 2025-11-25 23:20 +0100
              Bug#1121085: Landlock: Workaround a bug in RHEL 9 kernel Lasse Collin <lasse.collin@tukaani.org> - 2025-11-26 11:20 +0100

#1270974 — Bug#1121085: Landlock: Workaround a bug in RHEL 9 kernel

Package: xz-utils
Version: 5.8.1-1
Severity: normal

Dear fellow Maintainer,

RedHat has released a broken kernel 5.14.0-611.el9, which contains a
backport of the landlock API 6. Sadly they forgot one patch, so the API
6 is incomplete. XZ depends on that and aborts with the following error
message:
> xz: Failed to enable the sandbox

Sadly there is no runtime option to disable using the sandbox.

This is a problem when the docker images "debian:trixie" or
"debian:forky" are used on a RedHat powered host (CentOS Stream CoreOS
9.0.20250827-0).

Therefore it would help if Debian could cherry-pick
https://github.com/tukaani-project/xz/commit/5630c33a43a28a3d11030aa9d25fa8617e98da91
into `xz-utils` and release fixed versions for both "stable-security"
and "unstable".

So far I have seen `tar -J` failing as it calls `xz` as a child process,
which then aborts with the above message.

I have *not* seen `dpkg-deb` fail as it only links to `liblzma`, which
by default does not use the landlock sandbox.


So far we have tried to overwrite `lsm=` via the Linux Kernel command
line to remove `landlock` from the list of enabled LSMs, but that was
not successful so far.

An alternative might be to configure a reduced SECCOMP profile for out
k8s cluster, where all 3 syscalls for landlock are removed:
```console
$ grep landlock_ /usr/share/containers/seccomp.json
				"landlock_add_rule",
				"landlock_create_ruleset",
				"landlock_restrict_self",
```

Thank you
Philipp Hahn
-- System Information:
Debian Release: 13.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.12.57+deb13-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xz-utils depends on:
ii  libc6     2.41-12
ii  liblzma5  5.8.1-1

xz-utils recommends no packages.

xz-utils suggests no packages.

-- no debconf information

[toc] | [next] | [standalone]

#1271077

On Thu, 20 Nov 2025 20:08:01 +0100 Philipp Matthias Hahn
<pmhahn@debian.org> wrote:
> Therefore it would help if Debian could cherry-pick
> https://github.com/tukaani-project/xz/commit/5630c33a43a28a3d11030aa9d25fa8617e98da91
> into `xz-utils` and release fixed versions for both "stable-security"
> and "unstable".

I wrote the above commit and linked to it from the xz issue[1], where
you have commented too. Have you tested that this workaround actually
works on a buggy RHEL 9 kernel? So far I haven't heard any reports, via
any communication channel, if the commit works or not. Currently the
commit only exists in a temporary branch, so if something like it is
merged, the final version might differ.

[1] https://github.com/tukaani-project/xz/issues/199

-- 
Lasse Collin

[toc] | [prev] | [next] | [standalone]

#1271317

I have merged the following commits to master and v5.8 in upstream
xz.git:

ee75c76958dd Landlock: Cache the ABI version
2b2652e914b1 Landlock: Workaround a bug in RHEL 9 kernel
8bb516887c19 Landlock: Add missing #ifdefs

They will be in xz 5.8.2 unless Red Hat fixes their kernel soon.

I don't have an opinion if Debian should include those commits in
trixie. Debian itself doesn't need them, but without them one cannot
run trixie's xz in a container on RHEL 9's current kernel.

-- 
Lasse Collin

[toc] | [prev] | [next] | [standalone]

#1271323

On 2025-11-23 21:55:18 [+0200], Lasse Collin wrote:
> They will be in xz 5.8.2 unless Red Hat fixes their kernel soon.

I'm trying to ping someone on the RHEL side.

Sebastian

[toc] | [prev] | [next] | [standalone]

#1271324

On 2025-11-23 Sebastian Andrzej Siewior wrote:
> On 2025-11-23 21:55:18 [+0200], Lasse Collin wrote:
> > They will be in xz 5.8.2 unless Red Hat fixes their kernel soon.  
> 
> I'm trying to ping someone on the RHEL side.

Thanks! Just in case you haven't read the thread on GH, see at least
this message:

https://github.com/tukaani-project/xz/issues/199#issuecomment-3566988886

-- 
Lasse Collin

[toc] | [prev] | [next] | [standalone]

#1271601

On 2025-11-23 22:54:47 [+0200], Lasse Collin wrote:
> On 2025-11-23 Sebastian Andrzej Siewior wrote:
> > On 2025-11-23 21:55:18 [+0200], Lasse Collin wrote:
> > > They will be in xz 5.8.2 unless Red Hat fixes their kernel soon.  
> > 
> > I'm trying to ping someone on the RHEL side.
> 
> Thanks! Just in case you haven't read the thread on GH, see at least
> this message:
> 
Thanks.
I just read it. And I've been told that a proper fix is not happening
any time soon.

That is the second workaround for the redhat distro if I am not
mistaken.

Sebastian

[toc] | [prev] | [next] | [standalone]

#1271662

On 2025-11-25 Sebastian Andrzej Siewior wrote:
> I just read it. And I've been told that a proper fix is not happening
> any time soon.

Some progress is happening at Red Hat side:

https://github.com/tukaani-project/xz/issues/199#issuecomment-3574316280

I don't know how long it will take to be in a stable kernel. Follow the
GH thread for updates.

> That is the second workaround for the redhat distro if I am not
> mistaken.

Yes, although these are quite different issues. The first issue came
from a broken patch in RHEL/CentOS 7, which some not-Red-Hat packagers
decided to use to be ABI compatible with CentOS 7, and so more binaries
with the ABI issue were made. In a way the problem became contagious
and spread outside of RHEL/CentOS (not far but still).

The current RHEL/CentOS 9 kernel issue isn't contagious in this sense,
and likely it will be fixed at some point in RHEL/CentOS 9.

If xz 5.8.2 is released somewhat soon, perhaps one option would be to
have it in trixie-backports. Putting it into trixie-security feels odd
when it's not fixing any bug in xz itself, let alone fixing a security
bug. But I understand it would be more convenient to some users.
Luckily I don't need to decide what Debian does. ;-)

-- 
Lasse Collin

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web