## Host environment - Operating system: Ubuntu 24.04 (in GitHub Actions / Buildx containers) - OS/kernel version: Linux 6.8.0-1065-aws, x86_64 host - Architecture: x86_64 - QEMU flavor: qemu-aarch64 (linux-user mode, registered via binfmt_misc) - QEMU version: qemu-aarch64 10.2.3 (qemu-v10.2.3-68), as shipped by tonistiigi/binfmt@sha256:400a4873b838d1b89194d982c45e5fb3cda4593fbfd7e08a02e76b03b21166f0 (the standard arm64 registration on GitHub Actions / Buildx); binfmt_misc flags: PF - QEMU command line: ``` docker run --rm --platform linux/arm64 \ -v "$PWD:/fx:ro" \ -e GODEBUG=gctrace=1 -e GOGC=1 -e GOMEMLIMIT=2MiB \ alpine:3.19 /fx/repro-arm64 ``` ## Emulated/Virtualized environment - Operating system: Alpine Linux 3.19 (guest container); reproducer itself is a fully static binary - OS/kernel version: n/a — linux-user emulation; guest userspace shares the 6.8.0-1065-aws host kernel - Architecture: ARM64 (linux/arm64) ## Description of problem Under linux-user emulation (qemu-aarch64), guest memory that the guest still considers live is corrupted when the guest discards pages via madvise(MADV_DONTNEED). Observed with statically linked Go binaries whose runtime scavenger is under constant pressure (GOMEMLIMIT set low, GC running continuously); the Go runtime then reports heap corruption of live objects, which cannot happen absent external corruption: - `runtime: marked free object in span 0x…, elemsize=N freeindex=0` - `fatal error: found bad pointer in Go heap` - `fatal error: acquireSudog: found s.elem != nil in cache` - `concurrent map writes` (in a single map-free program — impossible) - SIGSEGV in fmt/memmove The corruption disappears completely when the guest is steered away from MADV_DONTNEED discards via `GODEBUG=madvdontneed=0` (which makes the Go runtime use MADV_FREE/MADV_DONTNEED fallback behavior such that pages are not discarded): 20/20 clean runs of the reproducer, and 0/100 crashes across our larger binaries (2.4MB unpatched + patched variants, GOMAXPROCS 1 and 16). This points at the guest madvise(MADV_DONTNEED) handling path in the target_madvise implementation. Expected behavior: guest madvise(MADV_DONTNEED) must never corrupt memory the guest still considers live. Version claim check: golang/go#77572 (qemu 10.0.4) was closed as a QEMU bug stating "10.0.6+ is known to work". 10.2.3 still corrupts under this workload (GOMEMLIMIT-driven constant scavenging) — suggesting a regression in the 10.1/10.2 target_madvise path, or a workload class that report did not exercise (cf. 7f2464103035, b7353da5c2c0 — recent target_madvise changes). Impact: tonistiigi/binfmt :latest ships 10.2.3 — every emulated arm64 Go build/run under a memory limit is exposed. Workaround: GODEBUG=madvdontneed=0. ## Steps to reproduce 1. Build the 24-line, dependency-free Go reproducer for linux/arm64: ```go package main import ( "fmt" "runtime" ) func main() { go func() { for { runtime.GC() } }() var sink [][]byte for i := 0; ; i++ { b := make([]byte, 4096) b[0] = byte(i) sink = append(sink, b) if len(sink) > 4096 { sink = sink[2048:] } if i%(1<<16) == 0 { fmt.Println("iter", i) } } } ``` ```sh GOOS=linux GOARCH=arm64 CGO_ENABLED=0 go build -o repro-arm64 . ``` 2. Run it under qemu-aarch64 (via binfmt_misc) in a container, with the Go scavenger under constant pressure (GOGC=1, GOMEMLIMIT=2MiB). Repeat ~20 times: ```sh for i in $(seq 1 20); do timeout 30 docker run --rm --platform linux/arm64 -v "$PWD:/fx:ro" \ -e GODEBUG=gctrace=1 -e GOGC=1 -e GOMEMLIMIT=2MiB \ alpine:3.19 /fx/repro-arm64 2>&1 | grep -cE 'marked free object|found bad pointer|fatal error|unexpected fault|acquireSudog|SIGSEGV|concurrent map' done ``` 3. Expected (default): 15/20 runs crash (5 clean, 5x1, 9x2, 1x3 signature lines) with heap-corruption fatal errors as listed above. 4. Control: repeat the same loop with `-e GODEBUG=gctrace=1,madvdontneed=0`. 20/20 runs are clean — no crashes at all. ## Additional information - Reproducer requires no external dependencies and no cgo (CGO_ENABLED=0, static binary, no dynamic loader). - Not a guest-side race: crash rate is GOMAXPROCS-independent (P=2: 9/12; P=16: 8–11/12 on the larger binaries). - Full validation matrix for the madvdontneed=0 workaround: 20/20 clean on the 24-line reproducer; 0/100 crashes across larger binaries (2.4MB unpatched + patched variants, GOMAXPROCS 1 and 16). - Related: golang/go#77572 (same class of corruption against qemu 10.0.4, closed as a QEMU bug with "10.0.6+ is known to work"); recent target_madvise changes 7f2464103035 and b7353da5c2c0 may be relevant. - This issue was discovered and triaged with the assistance of an LLM-based coding assistant; the reproducer, the run statistics, and the madvdontneed=0 control experiment were fully validated by the reporter prior to submission. <!-- The line below ensures that proper tags are added to the issue. Please do not remove it. -->