<!-- This is the upstream QEMU issue tracker. If you are able to, it will greatly facilitate bug triage if you attempt to reproduce the problem with the latest qemu.git master built from source. See https://www.qemu.org/download/#source for instructions on how to do this. QEMU generally supports the last two releases advertised on https://www.qemu.org/. Problems with distro-packaged versions of QEMU older than this should be reported to the distribution instead. See https://www.qemu.org/contribute/report-a-bug/ for additional guidance. If this is a security issue, please consult https://www.qemu.org/contribute/security-process/ --> ## Host environment - Operating system: Debian 12 and Debian 13 containers (also reproduced with distro packages on Ubuntu 24.04, Ubuntu 26.04, Fedora 44, Debian 13 and Debian unstable) - OS/kernel version: Linux 7.0.0-31-generic (containers share the host kernel) - Architecture: x86_64 - QEMU flavor: qemu-aarch64 (linux-user) - QEMU version: reproduced with current master, commit d7a65d1793 (2026-10-03, "11.1.50"), and with the 11.1.2 and 8.2.0 release tarballs. Not reproducible with 8.0.4 and 8.1.0. - QEMU command line: `QEMU_STRACE=1 ./qemu-aarch64 -L rootfs rootfs/usr/bin/perl -e 'my @a; push @a, "x" x 1000 for 1..30000'` ## Emulated/Virtualized environment - Operating system: Debian 12 (bookworm) arm64 user space, glibc 2.36 - OS/kernel version: n/a (user mode) - Architecture: aarch64 ## Description of problem With the default configuration (no `-R` and no `QEMU_RESERVED_VA`) every `brk()` call that tries to grow the heap of an aarch64 position independent executable fails. QEMU returns the previous break: ``` brk(NULL) = 0x00007bdf7b3f9000 brk(0x00007bdf7b41a000) = 0x00007bdf7b3f9000 <- growth refused, old break returned ``` In the test program above all 231 growth requests are refused and none succeed. On 8.1.0 and earlier the same test grants every request. glibc falls back to `mmap()` and the program keeps working, but `__brk()` has already set `errno = ENOMEM` (sysdeps/unix/sysv/linux/brk.c), and nothing clears it. Software that looks at `errno` after a call that succeeded then reports a spurious "Cannot allocate memory". Real world effect: apt 2.6.1 (Debian 12) in an arm64 chroot under qemu-user intermittently fails with ``` E: Could not read from /var/lib/apt/lists/... - getline (12: Cannot allocate memory) ``` because it checks `errno != 0` after a successful `getline()`. That is an apt bug (Debian #1021781, already fixed on apt main), but the refused `brk` is what exposes it, and it did not happen with older QEMU. ## Steps to reproduce 1. Get an arm64 user space without needing any emulation: ``` cid=$(docker create --platform linux/arm64 debian:bookworm /bin/true) mkdir rootfs && docker export "$cid" | tar -x -C rootfs ``` 2. Build QEMU (Python 3.12 or newer is needed for current master): ``` git clone https://gitlab.com/qemu-project/qemu.git && cd qemu && mkdir build && cd build ../configure --target-list=aarch64-linux-user --disable-docs --disable-tools --disable-system make -j"$(nproc)" ``` 3. Run the test and look at the `brk` calls: ``` QEMU_STRACE=1 ./qemu-aarch64 -L ../../rootfs ../../rootfs/usr/bin/perl \ -e 'my @a; push @a, "x" x 1000 for 1..30000' 2>&1 | grep -E ' brk\(0x' ``` Expected (8.1.0 and earlier): each `brk(NEW) = NEW`. Actual (8.2.0 and later): each `brk(NEW) = OLD`. ## Additional information - Distro packages show the same split: refused with Ubuntu 24.04 (8.2.2), Debian 13 (10.0.13), Ubuntu 26.04 (10.2.1), Fedora 44 (10.2.2) and Debian unstable (11.1.2); granted with Debian 12 (7.2.22). Ubuntu 22.04 (6.2) is mixed (123 of 231). - `QEMU_RESERVED_VA` makes `brk` work. - Related issues: #1756 (closed, a `brk(NULL)` problem from the same linux-user series). #1325 (open, `cc1plus` segfault in a `qemu-aarch64-static` chroot) might share the cause. - Downstream tracking: apt side https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021781 Thank you so much! Roberto <!-- The line below ensures that proper tags are added to the issue. Please do not remove it. -->