Panic when using coreutils 0.8.0 on kernel versions < 6.4

[EmilSodergren]

Hi,

I get a panic on an .unwrap() when running coreutils 0.8.0. This happens when chrooting in to a debootstrapped Ubuntu 26 folder on a Ubuntu 22 host. Consider the following reproducer:

#!/bin/bash

sudo debootstrap --components="main" --arch=amd64 resolute u26-with-uutils-0.8.0 https://archive.ubuntu.com/ubuntu/
sudo cp -r u26-with-uutils-0.8.0 u26-with-uutils-0.7.0

wget https://github.com/uutils/coreutils/releases/download/0.7.0/coreutils-0.7.0-x86_64-unknown-linux-gnu.tar.gz
tar -xf coreutils-0.7.0-x86_64-unknown-linux-gnu.tar.gz coreutils-0.7.0-x86_64-unknown-linux-gnu/coreutils
sudo cp coreutils-0.7.0-x86_64-unknown-linux-gnu/coreutils u26-with-uutils-0.7.0/usr/bin/coreutils
for bin in u26-with-uutils-0.7.0/usr/lib/cargo/bin/coreutils/*; do
  sudo ln -f u26-with-uutils-0.7.0/usr/bin/coreutils "${bin}"
done

sudo chroot u26-with-uutils-0.7.0 bash -c "ls --version && ls && exit" # <-- This works everywhere
sudo chroot u26-with-uutils-0.8.0 bash -c "ls --version && ls && exit" # <-- This breaks on Ubuntu 22

When run on a machine with the following specs:
Linux my-u24-computer 6.8.0-110-generic #110-Ubuntu SMP PREEMPT_DYNAMIC Thu Mar 19 15:09:20 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux
everything works as expected.

BUT on this:
Linux my-u22-computer 5.15.0-173-generic #183-Ubuntu SMP Fri Mar 6 13:29:34 UTC 2026 x86_64 GNU/Linux
I get the following error:

ls (uutils coreutils) 0.7.0
bin  boot  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var
 
thread 'main' (34588) panicked at /build/rust-coreutils-u5JpDp/rust-coreutils-0.8.0/rust-vendor/rustix/src/backend/linux_raw/param/auxv.rs:269:22:
called `Result::unwrap()` on an `Err` value: ()
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
bash: line 1: 34588 Aborted                    ls --version

Is this to be expected? Is there something we could do to fix it? Is Ubuntu 22 too old for coureutils 0.8.0?

[oech3]

Is /proc mounted when you run the binary?

[EmilSodergren]

No it does not seem like it is.

[oech3]

I know ubuntu had patch depending on /proc/self/exe to match with AppArmor profile which is not part of upstream binary (this repo's binary).

If you can get 0.8.0 from (beta) Ubuntu's repo, you should try it.

[EmilSodergren]

Yes, mounting proc works from Ubuntu 22! But... it is not needed for 0.7.0, or on a Ubuntu 24 host?

[oech3]

I don't know. /proc dependency is downstream patch specific.

[oech3]

On Arch Linux with binary from main, I have

> unshare -rm bash -c "mount -t tmpfs tmpfs /proc &
& coreutils ls /proc"
# empty result

Note that same test on Ubuntu needs to enable NS sandbox.

[EmilSodergren]

Ok, thank you for the quick feedback!
Solution: Use Ubuntu 24 OR mount /proc from host (not possible when running debootstrap inside a docker build)

[oech3]

By the way, if upstream binary actually depends on /proc, it is a bug.

[EmilSodergren]

Ok, is that something I can check if it is? I would like to help but, my knowledge of how thing work are sadly not deep enough. I have never mounted a /proc-directory manually before today :) .

[oech3]

Welcome. But it might hard to verify.
thread 'main' (34588) panicked at /build/rust-coreutils-u5JpDp/rust-coreutils-0.8.0/rust-vendor/rustix/src/backend/linux_raw/param/auxv.rs:269:22:
rustix has many method to get binary name which might depending on toolchain or host .

[oech3]

Would you try LD_SHOW_AUXV=1 grep --version | grep AT_EXECFN inside of container?

[EmilSodergren]

We have been investigating this further and have found the following:
Looking at this commit: uutils/coreutils 2d60946 it seems like it introduces the use of rustix::param::linux_execfn() which seems to be defined here. It tries to use the syscall PR_GET_AUXV that was introduced in kernel 6.4 (Ubuntu 22 was released with kernel 5.15) with the fallback to use /proc/self/auxv. Thus on kernels older than 6.4 this indeed introduces a dependency on /proc. Does your previous quote still hold in this case?

By the way, if upstream binary actually depends on /proc, it is a bug.

If so, we should maybe report this upstream? What do you say?

[oech3]

Oops. I was considering that rustix directly extract AT_EXECFN from stack always...
cc @sunfishcode
Can we do that without unsafe?

You can reopen this issue and add kernel version to the title.