## Host environment - Operating system: Fedora CoreOS, as distributed in the `podman-machine-os` OCI images (`quay.io/podman/machine-os`), tags `5.8` and `6.1`. Running as a `podman machine` VM on macOS/Apple Silicon via the `applehv` provider (i.e. the aarch64 VM itself is not QEMU-virtualized — QEMU is only used inside it for linux-user emulation of x86_64 binaries). - OS/kernel version: `6.18.10-200.fc43.aarch64` (tag `5.8`); Fedora CoreOS 44 kernel 6.18.x aarch64 (tag `6.1`, exact `uname -a` not captured) - Architecture: aarch64 - QEMU flavor: `qemu-x86_64-static` (linux-user mode) - QEMU version: ``` qemu-x86_64 version 10.1.3 (qemu-10.1.3-1.fc43) qemu-x86_64 version 10.2.2 (qemu-10.2.2-1.fc44) ``` Both reproduce the bug. `qemu-x86_64 version 9.1.2 (qemu-9.1.2-3.fc41)` and `9.1.3` do not. - QEMU command line: No minimal standalone reproducer is attached yet — both reproductions below came from running third-party Go binaries (not ours to redistribute) invoked transparently via binfmt_misc when running an `x86_64` container on the aarch64 host. Any Go \>=1.22 binary that exercises the runtime's netpoll (e.g. performs network I/O) run via `qemu-x86_64-static ./some-binary` should trigger it — see Steps to reproduce. ## Emulated/Virtualized environment - Operating system: Any Linux x86_64 userspace containing a Go \>=1.22 binary — reproduced inside a Debian bookworm-slim based container, but not specific to that distro. - OS/kernel version: N/A — linux-user mode has no separate guest kernel; syscalls are translated directly to the aarch64 host kernel. - Architecture: x86_64 ## Description of problem Running x86_64 Go binaries (compiled with Go \>=1.22) under `qemu-x86_64-static` on an aarch64 host crashes with SIGSEGV. The same binary works correctly under QEMU 9.1.x, which returns `ENOSYS` for `epoll_pwait2`, causing Go's runtime to fall back to `epoll_pwait` (correct/expected behavior for older QEMU). The Go runtime crashes with SIGSEGV in `netpoll_epoll.go` shortly after startup. The faulting address is in kernel space (`0xffffffff...`), suggesting `epoll_pwait2` is returning a corrupt value — likely a raw kernel pointer — into what should be a user-space output buffer, which Go then dereferences as event data. Go 1.22+ detects `epoll_pwait2` support at startup via a test call. QEMU 10.x implemented `epoll_pwait2` via a patch merged in January 2026 (addressing issue #3210); the v1 of that patch was noted to have a missing `get_errno()` wrapper described as a "brown-paper-bag bug," and it appears the v2 fix did not fully resolve the return-value handling. Reproduced independently twice, \~4 months apart, with different QEMU point releases and different Go toolchains (1.23 and 1.24), so this is not specific to one Go point release or one QEMU point release — it has persisted across at least 3 QEMU point releases (10.1.3, 10.2.2, and implicitly whatever shipped in between) with no fix. QEMU 11.0 (released 2026-04-22) does not mention any epoll/`epoll_pwait2`/linux-user fix in its changelog or release announcement, so it likely is not fixed there either — **not yet tested directly against 11.x or git master**, flagging that gap for triage. ## Steps to reproduce 1. On an aarch64 host, obtain `qemu-x86_64-static` from QEMU \>=10.1.3 (or use one of the `podman-machine-os` images above). 2. Build any Go \>=1.22 program that does network I/O (anything using `net/http`, or that otherwise exercises the Go runtime's netpoll — this is not specific to any one binary). 3. Run: `qemu-x86_64-static ./program` 4. Observe SIGSEGV in `runtime.netpoll` shortly after startup. ## Additional information **Reproduction 1** — Go 1.23: ``` SIGSEGV: segmentation violation PC=0x43438e m=0 sigcode=1 addr=0xffffffff3d574e10 goroutine 0 [idle]: runtime.netpoll(0xc000022050?) runtime/netpoll_epoll.go:166 +0x24e runtime.findRunnable() runtime/proc.go:3581 +0x8c5 ... rsi 0xffffffff3d574e00 ← kernel address in user-space register ``` **Reproduction 2** — \~4 months later, different QEMU point release (10.2.2), different Go toolchain (1.24.0), different binary: ``` WARNING: SIGSEGV: segmentation violation PC=0x43b72e m=0 sigcode=1 addr=0xffffffff90d90e50 goroutine 0 gp=0x1063f20 m=0 mp=0x1064da0 [idle]: runtime.netpoll(0xc000020050?) .../go1.24.0.linux-amd64/src/runtime/netpoll_epoll.go:169 +0x24e fp=0xffff921ef9b0 sp=0xffff921ef328 pc=0x43b72e runtime.findRunnable() .../go1.24.0.linux-amd64/src/runtime/proc.go:3602 +0x8c5 fp=0xffff921efb28 sp=0xffff921ef9b0 pc=0x4484c5 runtime.schedule() .../go1.24.0.linux-amd64/src/runtime/proc.go:4017 +0xb1 fp=0xffff921efb60 sp=0xffff921efb28 pc=0x449a91 runtime.park_m(0xc000002380) .../go1.24.0.linux-amd64/src/runtime/proc.go:4141 +0x285 fp=0xffff921efbc0 sp=0xffff921efb60 pc=0x449f45 runtime.mcall() .../go1.24.0.linux-amd64/src/runtime/asm_amd64.s:459 +0x4e fp=0xffff921efbd8 sp=0xffff921efbc0 pc=0x47a66e goroutine 1 gp=0xc000002380 m=nil [select]: ``` **Workaround:** use a Go binary compiled with Go \<=1.21 (uses `epoll_pwait` instead of `epoll_pwait2`) — confirmed working under QEMU 10.1.3 and 10.2.2 (11.x untested). Alternatively, pin `qemu-user-static`/`podman-machine-os` to a build bundling QEMU \<=9.x (confirmed-good: `podman-machine-os:5.5`, QEMU 9.1.2). **References:** - QEMU issue #3210 — `epoll_pwait2` missing implementation / original feature request - January 2026 patch: `linux-user: implement epoll_pwait2 syscall` (v1 had missing `get_errno()` wrapper, "brown-paper-bag bug"; v2 added it but return-value handling still appears broken) - Go issue #53824 — `runtime: use epoll_pwait2 where available`, adopted in Go 1.22 - [QEMU 11.0 release notes/changelog](https://www.qemu.org/2026/04/22/qemu-11-0-0/) (2026-04-22) — no `epoll_pwait2` fix mentioned