CVE-2026-31431 (Copy Fail) - Så hanterade vi den

Förra veckan offentliggjordes en allvarlig lokal privilegieeskalering i Linux-kärnan: CVE-2026-31431, med smeknamnet "Copy Fail". Den påverkar ett brett spann av kärnversioner i moderna Linux-distributioner, och ett publikt exploit dök snabbt upp efter offentliggörandet.

Jag vill vara tydlig med vad som hände, vad det betyder för Appbox och vad vi har gjort åt det. Kortversionen: tack vare hur våra containrar är byggda var appar som körs med user namespace remapping redan skyddade mot att detta skulle bli host root, även innan patchade kärnor rullades ut. Igår (May 4, 2026) genomförde vi dessutom akut underhåll för att uppgradera varje server till en patchad kärna, så buggen är nu helt borta från vår flotta.

Vad är "Copy Fail"?

CVE-2026-31431 är en brist i kärnans kryptografiska API AF_ALG. Genom att binda till ett specifikt cipher (authencesn(hmac(sha256),cbc(aes))) och missbruka hur kärnan splajsar sidor till en tillfällig scratch-buffer kan en opriviligierad lokal användare skriva godtyckliga 4-byte-block direkt till page cache för filer som användaren inte ska ha rätt att ändra, inklusive SUID-binärer som /usr/bin/su.

När page cache-kopian av su har skrivits över med en liten skadlig ELF kör nästa anrop angriparens kod som UID 0. Då är hosten förlorad.

För de riktigt tekniska detaljerna (shellcode-disassemblering, syscall-spårningar, alltihop) är Andrea Veris genomgång utmärkt: CVE-2026-31431: Copy Fail vs. rootless containers. Han gjorde också arbetet med att visa, med eBPF och uid_map-bevis, exakt det vi ska prata om härnäst: att user namespaces neutraliserar detta exploit.

Varför Appbox-appar redan var skyddade

Exploit-kedjan bygger på att setuid(0) faktiskt ger host root. I en container som körs med user namespaces aktiverade är det inte vad som händer.

User namespaces mappar containerns UID-utrymme till ett annat, opriviligierat UID-intervall på hosten. Så när exploiten lyckas inne i containern och setuid(0) returnerar lyckat, mappas det resulterande "root"-skalet till en vanlig opriviligierad host-användare, inte riktig root. Shellcode körs, prompten ändras till #, men på hosten:

podman     27943  0.0  0.0   2984  2028 pts/1    S+   22:15   0:00 sleep 100

Det är allt. Ingen åtkomst till host-filer, ingen /etc/shadow, ingen host root. Containerns namespace-gräns stoppar detta från att bli en host-root-escape.

På plattformsnivå får varje Appbox sin egen Docker-daemon som startas med user namespace remapping aktiverat. I pseudokod ser det mer ut så här:

start_docker_daemon(
  userns_remap = appbox_id,
  container_namespace = appbox_id
)

Den mappningen backas av ett dedikerat underordnat UID/GID-intervall på hosten:

write "/etc/subuid" -> "<appbox-id>:<host-subuid-start>:65536"
write "/etc/subgid" -> "<appbox-id>:<host-subgid-start>:65536"

Utöver det kan appdefinitioner fortfarande uttryckligen åsidosätta UsernsMode när en app behöver särskild hantering:

container_config = {
  userns_mode: app.userns_mode,
  network_mode: app.network_mode,
  ...
}

Det korrekta sättet att beskriva det är alltså: user namespace remapping är en del av plattformens standardläge, och undantag per app är explicita. Det finns ett litet antal appar som behöver andra inställningar eftersom de exponerar funktionalitet som kräver ytterligare capabilities, och de fallen hanteras separat.

Med andra ord: för appar som körs med den normala remappade konfigurationen kunde Copy Fail inte göra ett containerintrång till host root.

Vad vi ändå ville åtgärda

User namespaces stoppar host-escapen, men de får inte buggen att försvinna inne i containern. En angripare skulle fortfarande kunna eskalera till "container root" inom appens gräns, vilket, även om det är isolerat, fortfarande är dålig hygien. Själva kärnan var sårbar, och vi ville få bort det.

När vi fick reda på buggen började vi omedelbart bedöma vår exponering. Även om user namespace remapping redan blockerade host-escape-delen av problemet för vår normala appkonfiguration ville vi ändå få bort den underliggande kärnbuggen så snabbt som möjligt.

Vad vi gjorde igår

På söndagskvällen schemalade vi akut underhåll till Monday, May 4, 2026, den tidigaste luckan då vi kunde rulla ut en kärnuppgradering över hela flottan.

Under fönstret:

• Uppgraderades varje host med de officiella Debian-kärnpaketen som innehåller "Copy Fail"-fixen.
• Målet var enkelt: ta bort den sårbara kärnvägen helt, inte bara förlita oss på vår befintliga namespace-isolering.

Underhållet är slutfört. Varje Appbox-host kör nu en patchad kärna.

Vad detta betyder för dig

• Du behövde inte göra någonting. Dina appar fortsatte köras och eventuella korta störningar under underhållsfönstret var den enda kundsynliga effekten.
• Även före gårdagens patch innebar user namespace remapping att den här buggen inte kunde göra ett normalt appintrång till host root. Det är exakt den typen av scenario som den här isoleringsmodellen finns till för.
• Framåt är vår policy oförändrad: user namespaces är fortsatt aktiverade som standard, och de mycket få undantagen går igenom extra säkerhetsgranskning.

Den större bilden

Det här är en av de CVE:er där rubriken ("lokal privilegieeskalering, publikt exploit, varje modern kärna påverkas") låter katastrofal, och för många miljöer med delade tenants var den verkligen det. Anledningen till att den inte var katastrofal för oss är samma anledning till att vi för flera år sedan fattade arkitekturbeslut som ibland kostar oss lite kompatibilitet: vi kör appar med minsta möjliga behörighet inbyggt i containerlagret, inte påbultat i efterhand.

Defense in depth fungerar faktiskt. Bugg i kärnlagret? Namespace-lagret fångade den. Bugg i namespace-lagret? Capability drops och seccomp fångar det mesta. Vi låtsas inte att något enskilt lager är perfekt, vi ser bara till att det alltid finns ett nästa lager.

Om du har några frågor om detta, eller om hur dina specifika appar är konfigurerade, hör gärna av dig.

Har du frågor? Kontakta oss på support@appbox.co eller öppna ett ärende på billing.appbox.co.