A latent issue found in ntdll while adding Apple Silicon macOS host support for building Proton (https://github.com/ValveSoftware/Proton/pull/10087). Proton's Wine version builds and then runs 64-bit and 32-bit versions of wine in order to create a base prefix as part of a redistributable package phase, all within a guest linux/amd64 container. 32-bit i386 processes translate with QEMU in this host context, while 64-bit x86_64 uses the host's Rosetta 2 translation system. It is likely but not confirmed that QEMU would similarly be used and 32-bit wine would fail to run when virtualizing linux/amd64 on linux/arm64 hardware. mmap_add_reserved_area() and mmap_remove_reserved_area() trim a single byte when addr + size wraps to 0, which leaves an area whose end is 0xffffffff. alloc_virtual_heap() then derives its mapping address from that end and passes an unaligned address to anon_mmap_fixed(), tripping the alignment assertions added in d813ffc3557 (ntdll: Align virtual memory allocations to the host page size). Trim a whole page instead so the area bounds stay aligned. The wrap-around trim dates to 94d74b5fedf (2004), long before the alignment invariant existed. It is only reached when a reserved area ends exactly at 4GB, which requires mmap_init() to take the reserve_area( user_space_limit, 0 ) branch -- that is, when the initial stack is not near the top of the 32-bit address space. Native Linux and all other native x86 platforms place it near the top, so the branch is dead there; qemu-user lays out the guest address space itself and maps the stack around 0x40000000, making it reachable and aborting every 32-bit process at startup. Nothing verifies requested against recorded area bounds, and the top 64k allocation granularity block was already unusable due to the one-byte trim, so widening it to a page costs nothing allocatable. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11736