/usr/bin/qemu-aarch64-static:11:have_mmap_lock:page_set_flags:target_mmap:load_elf_image:load_elf_binary

Hi,
I've checked these builds and run e.g. a full debootstrap of groovy within qemu-arm64/s390x-static and all is working fine without crash.

For now I have to assume that whatever is special is special to that payload "/check" that you are trying to load/emulate.

It almost looks like a test from a cross build toolchain or such. But I failed to find which one that would be. Maybe tat even is an intended fail, but I miss why it would then only hit this particular new version.

If anyone is affected and has that payload please I'd appreciate if you
a) could explain your use case what/why is going on
b) attach that payload

Since it only affects groovy and even only since https://launchpad.net/ubuntu/+source/qemu/1:5.0-5ubuntu9.3 I've marked it as such.

The breakage is on:

1. page_set_flags calls assert_memory_lock();
2. that is defined as tcg_debug_assert(have_mmap_lock())
3. That is just
 25 static __thread int mmap_lock_count;
 ...
 41 bool have_mmap_lock(void)
 42 {
 43 return mmap_lock_count > 0 ? true : false;
 44 }
4. if that returns false then this will with the config qemu has for qemu-user-static turn into
 242 do { if (!(X)) { __builtin_unreachable(); } } while (0)

That is our segfault.
So we are actually looking at a lack of an expected mmap lock.

We didn't mess with the locking or MM of qmeu-user-static.
The non-wrong linking should - if anything - in that regard only help.

# Note: The following can even be done in a LXD container

apt install qemu binfmt-support qemu-user-static debootstrap schroot
sudo qemu-debootstrap --arch=arm64 focal arm64-ubuntu
sudo qemu-debootstrap --arch=s390x focal s390x-ubuntu

echo "[arm64-ubuntu]
description=Test G (arm64)
directory=$(pwd)/arm64-ubuntu
root-users=$(whoami)
users=$(whoami)
type=directory" | sudo tee /etc/schroot/chroot.d/arm64-ubuntu

echo "[s390x-ubuntu]
description=Test G (s390x)
directory=$(pwd)/s390x-ubuntu
root-users=$(whoami)
users=$(whoami)
type=directory" | sudo tee /etc/schroot/chroot.d/s390x-ubuntu

# The creation of the above has run qemu*static a lot already.
# But one can even play around, so far all has been working for me

$ schroot -c arm64-ubuntu
$ md5sum /dev/urandom

$ schroot -c arm64-ubuntu
$ md5sum /dev/urandom

And on the host we see how that actually runs:

root@g:~# ps axlf | grep static | grep -e s390x -e aar
4 0 103720 103588 20 0 226524 13568 do_wai Sl pts/1 0:00 \_ /usr/bin/qemu-aarch64-static /bin/bash
0 0 103748 103720 20 0 224124 7652 - Rl+ pts/1 0:20 \_ /usr/bin/qemu-aarch64-static /usr/bin/md5sum /dev/urandom
4 0 103566 103425 20 0 225508 13784 do_wai Sl pts/0 0:00 \_ /usr/bin/qemu-s390x-static /bin/bash
0 0 103751 103566 20 0 223280 7236 - Rl+ pts/0 0:19 \_ /usr/bin/qemu-s390x-static /usr/bin/md5sum /dev/urandom

I've exercised groovy's new qemu*static a lot on arm64 and s390x.
But I can't recreate that crash.
I'm back at needing that payload to have any chance to continue ...

Potentially related, but not necesarily a dup of bug 1914014

Hirsute seems also affected since 1:5.2+dfsg-9* with a slightly different, but still same signature. I marked bug 1924991 as dup.
=> https://errors.ubuntu.com/problem/dd6db6d283c9912220e4f2c8218f9de08bd63cfb

[Expired for qemu (Ubuntu Hirsute) because there has been no activity for 60 days.]

[Expired for qemu (Ubuntu) because there has been no activity for 60 days.]

[Expired for qemu (Ubuntu Groovy) because there has been no activity for 60 days.]

I happened to find a crash file in /var/crash/ regarding this. You can find it here:

https://errors.ubuntu.com/oops/99339bf8-cd43-11eb-9b1b-fa163e6cac46

I don't recall doing anything that would have prompted this crash. It's worth noting that I'm using an amd64 system.