[Bug 2172422] Re: Regression 7.0.0-42/-43: Go 1.24 programs livelock in setuid (gosu); official DB Docker images hang on start

Root cause narrowed down to AppArmor signal mediation. On 7.0.0-42 and -43, the kernel log shows docker-default denying gosu's signals to its own threads, with the peer labelled as a stack: apparmor="DENIED" operation="signal" class="signal" profile="docker-default" pid=30562 comm="gosu" requested_mask="send" denied_mask="send" signal=rtmin+1 peer="docker-default//&unconfined" pid 30562 is the stuck gosu process. SIGRTMIN+1 is the signal Go's runtime uses for doAllThreadsSyscall (setuid/setgid on every thread). The threads never receive it, so the main thread spins in sched_yield forever. Counts of gosu signal denials per boot on the same host: 7.0.0-38: 0 7.0.0-42: 34x rtmin (+ int/term/urg) 7.0.0-43: 22x rtmin Control test: the same gosu 1.19 binary on 7.0.0-42 in a minimal KVM guest on the same CPU (no AppArmor policy, no Docker) completes instantly. So scheduling/futex are fine; the regression is that a container task's own threads are now labelled "docker-default//&unconfined" instead of "docker-default", so docker-default's "signal peer=docker-default" rule no longer matches. Affects any Docker container under the docker-default profile whose entrypoint drops privileges with Go >= 1.16-style all-threads setuid (official mariadb/postgres/mongo images). -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2172422 Title: Regression 7.0.0-42/-43: Go 1.24 programs livelock in setuid (gosu); official DB Docker images hang on start Status in linux package in Ubuntu: Confirmed Bug description: Summary ------- After upgrading from 7.0.0-38 to 7.0.0-42 (resolute-updates, published 2026-10-28), gosu 1.19 (built with Go 1.24.6) never returns. The official mariadb, postgres and mongo Docker images use gosu to drop privileges in their entrypoints, so all of those containers hang at "Switching to dedicated user" indefinitely. 7.0.0-43 from -proposed shows the same behavior. Booting back to 7.0.0-38 fixes it immediately. Reproducer ---------- timeout 60 docker run --rm --entrypoint gosu mariadb:10.11 nobody id 7.0.0-38: prints "uid=65534(nobody) gid=65534(nogroup) ..." instantly 7.0.0-42: hangs until the timeout 7.0.0-43: hangs until the timeout On -42 and -43 this was tested at 10+ minutes of uptime, after the boot-time load had settled. Stuck gosu processes were still alive after 270+ seconds. On -42 the host stayed in this state for ~10 hours (database containers restarted ~180 times each, never starting). Observations ------------ - strace -f of a stuck gosu process (6 threads): main thread: sched_yield() = 0, repeated forever other 5: futex(..., FUTEX_WAIT_PRIVATE, 0, NULL) (never woken) This looks like Go's all-threads setuid/setgid path (runtime.doAllThreadsSyscall) waiting forever for threads that are never woken or signaled. - gosu 1.13 built with Go 1.16.5 (image mariadb:10.6.4-focal) WORKS on 7.0.0-43. Only the newer Go runtime (1.24.6) is affected. - Same host, same images; only the kernel changed. The same images work on other hosts running 7.0.0-38. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2172422/+subscriptions