On Wed, 20 Nov 2024, Kees Cook wrote: > > >> Interestigly there is another report in Debian which identifies the > > >> backport of upstream commit 44c76825d6eefee9eb7ce06c38e1a6632ac7eb7d > > >> to cause issues in the 6.1.y series: > > >> > > >> https://bugs.debian.org/1085762 > > >> https://lore.kernel.org/regressions/18f34d636390454180240e6a61af9217@xxxxxxxxx/T/#u > > > > >Thanks for the heads up! > > > > >This would appear to be the same bug (running qemu-aarch64 in user mode > > >on an x86 machine) ? > > >I've added Ulrich in recipients to confirm he's using qemu-user-static > > >like I was. > > > > pbuilder uses qemu inside the ARM64 chroot, yes. I don't know which variety of qemu, though. > > > > >Shame I didn't notice all his work, that would have saved me some > > >time :) > > > > Well, at least we now have confirmation from two different git bisects done by > > two different developers, pointing to the same commit ;-) > > It seems like the correct first step is to revert the brk change. It's > still not clear to me why the change is causing a problem -- I assume it > is colliding with some other program area. > > Is the problem strictly with qemu-user-static? (i.e. it was GCC running > in qemu-user-static so the crash is qemu, not GCC) That should help me > narrow down the issue. There must be some built-in assumption. And it's > aarch64 within x86_64 where it happens (is the program within qemu also > aarch64 or is it arm32)? > > Is there an simple reproducer? Also seeing /proc/<pid>/maps from a working case (without the patch) might give some clue. Thanks, -- Jiri Kosina SUSE Labs
