bug(envd): PostInit spawns unbounded MMDS-poll goroutines — one per /init retry

Inizia in packages/envd/internal/api/init.go, in PostInit, soprattutto alle righe 209-213, e analizza come viene avviato PollForMMDSOpts e come initLock è correlato a esso. Aggiungi il guard dello stato di esecuzione descritto nell’issue, quindi verifica che i tentativi ripetuti di /init lascino attiva al massimo una goroutine di polling MMDS, consentendo al contempo a un successivo ciclo di ripresa di eseguire nuovamente il polling.

Summary

PostInit unconditionally spawns a new goroutine on every call to poll MMDS. The orchestrator drives /init via an infinite retry loop, so when MMDS is not immediately reachable, goroutines accumulate inside the microVM without bound.

Root Cause

packages/envd/internal/api/init.go lines 209-213:

go func() {
ctx, cancel := context.WithTimeout(context.Background(), 60*time.Second)
defer cancel()
host.PollForMMDSOpts(ctx, a.mmdsChan, a.defaults.EnvVars)
}()

No guard prevents concurrent goroutine accumulation. initLock serialises body processing but the goroutine spawns after initLock.Release(1) so serialisation does not protect the spawn.

PollForMMDSOpts creates its own http.Client with DisableKeepAlives and ticks every 50ms issuing 2 HTTP requests per tick. Each goroutine lives up to 60 seconds.

Impact

At 100ms retry interval, 60 seconds of MMDS unavailability produces 600 concurrent goroutines, each making 40 connection-attempts/sec to 169.254.169.254 — 24000 TCP connections/sec total. This exhausts the VM ephemeral port range and can crash the envd control plane mid-resume.

Fix

Add an atomic.Bool guard to API struct and use CompareAndSwap in PostInit:

if a.mmdsPollRunning.CompareAndSwap(false, true) {
go func() {
defer a.mmdsPollRunning.Store(false)
ctx, cancel := context.WithTimeout(context.Background(), 60*time.Second)
defer cancel()
host.PollForMMDSOpts(ctx, a.mmdsChan, a.defaults.EnvVars)
}()
}

Caps concurrent MMDS-poll goroutines at 1 while preserving re-poll across resume cycles.