Copy Fail (CVE-2026-31431): 60-minuters nödpatchning för Linux, Kubernetes och AI-infrastruktur

Copy Fail (CVE-2026-31431): 60-minuters nödpatchning för Linux, Kubernetes och AI-infrastruktur

Kör du Linux på en multi-tenant-server har du till nästa omstart på dig att åtgärda Copy Fail-sårbarheten. Microsoft Threat Intelligence avslöjade CVE-2026-31431 den 1 maj 2026 — beröm till Theori för fyndet och Xint för 732-bytes-to-root write-upen. CVSS är 7,8 (Hög), och CERT-EU publicerade rådgivning 2026-005 samma dag.

Det som skiljer Copy Fail från mängden: det är den första stora Linux LPE som kringgår RuntimeDefault seccomp rakt ut ur lådan. Din "säkra" Kubernetes-pod med Pod Security Standards Restricted är i riskzonen. Läs det här och agera.

TL;DR: Vad du gör de nästa 60 minuterna

Har du inte tid att läsa mer, gör dessa sex saker nu:

1. Pausa produktionsdriftsättningar och ta en ögonblicksbild av /var/log/auth.log och kubectl get events -A innan du börjar rotera något.
2. Kör uname -r på varje nod. Är du under den patchade kerneln för din distro är du sårbar.
3. Inaktivera algif_aead omedelbart: echo "blacklist algif_aead" > /etc/modprobe.d/copy-fail.conf && rmmod algif_aead.
4. Applicera din distros Copy Fail-patch (Ubuntu USN, AlmaLinux ALSA, SUSE SU) och starta om.
5. Lägg till en Localhost seccomp-profil som nekar socket(AF_ALG, ...) på varje Kubernetes-nod och ladda om kubelet.
6. Granska de senaste 30 dagarnas auth.log och EDR för oväntade socket(AF_ALG)-systemanrop och eventuella nya setuid-binärer.

Den fullständiga genomgången — kommandon, distrospecifika patchar, K8s seccomp-profil — kommer nedan.

Vad som egentligen hände: inuti CVE-2026-31431

CVE-2026-31431 ("Copy Fail") är en Linux-kernelprivilegieeskaleringsbugg i algif_aead. Genom att öppna en AF_ALG-socket och trigga splice() med en fabricerad authenc-esn-begäran orsakar en oprivilegierad användare en 4-byte page-cache-skrivning som korrumperar setuid-binärer och ger root-åtkomst. CVSS är 7,8 (Hög).

Grundorsaken spåras tillbaka till en 2017-optimering i algif_aead — AF_ALG-socketgränssnittet som exponerar kernel-kryptografprimitiver mot användarutrymme. När Xints exploit matar rätt authenc-esn-begäran in i socketen och pipar det genom splice(), skriver optimeringen 4 byte förbi den avsedda bufferten in i page-cachen. Väljer man rätt offset skriver man om /usr/bin/sudo eller valfri annan setuid-binär på disken. Mainline-fixet landade som commit a664bf3d603d.

Exploiten är liten. Xint publicerade en fungerande PoC på 732 bytes, och triggerytan är nåbar inifrån en container. Det är den delen som bör få magen att vända sig.

"Dirty Pipe kontra Copy Fail" är en rimlig jämförelse. Båda är Linux-kernel-LPE:er som producerar godtyckliga page-cache-skrivningar. Dirty Pipe (CVE-2022-0847) missbrukade splice() in i en pipe; Copy Fail missbrukar splice() in i en algif_aead-socket. Båda kringgår standardcontainerns seccomp-standarder. Copy Fails twist är att AF_ALG-vägen är nåbar från Pod Security Standards Restricted med RuntimeDefault — samma spelplansform, annan kernelyta. Vi täckte svarsmönstret efter Vercel-intrånget och strukturen fungerar rakt av här.

Är du drabbad? 5-minuterstriage

Kör uname -r och jämför mot den patchade kerneln för din distro: Ubuntu 6.19.12, AlmaLinux/RHEL 7.0, SUSE 6.18.22. Kör sedan lsmod | grep algif_aead. Är modulen laddad och din kernel äldre än den patchade versionen är du sårbar. Är modulen frånvarande men /etc/modprobe.d inte svartlistar den är du fortfarande sårbar.

Kör dessa fyra kommandon på varje Linux-host du driver, i ordning:

# 1. Identifiera körande kernel
uname -r

# 2. Korsreferera mot per-distro-tabellen längre ner.
#    Ubuntu < 6.19.12 = sårbar. RHEL/AlmaLinux/Rocky < 7.0 = sårbar. SUSE < 6.18.22 = sårbar.
cat /etc/os-release | grep -E '^(NAME|VERSION_ID)='

# 3. Är modulen laddad?
lsmod | grep -E 'algif_(aead|skcipher)'

# 4. (Enbart Kubernetes) räkna noder du behöver triagera
kubectl get nodes -o wide

Ärlig anmärkning: returnerar lsmod tomt för algif_aead är du inte säker. En oprivilegierad användare kan själv köra modprobe algif_aead på de flesta distros, eftersom kmod inte grindar på kapabilitet för autoload-berättigade moduler. "Modul avladdad" är inte detsamma som "modul onåbar" förrän du lagt till svartlistfilen i steg 3 i TL;DR.

Vi testade algif_aead-borttagning på Ubuntu 24.04 LTS och Kubernetes 1.30 med containerd 1.7. Modulen laddades om utan problem för valfri användare med skalåtkomst tills vi lade till /etc/modprobe.d/copy-fail.conf. Behandla svartlistan som ett grundkrav, inte en reservplan.

Varför AI/ML- och Kubernetes-stackar löper högre risk

Egenhostade AI-arbetsbelastningar är oproportionerligt exponerade eftersom de rutinmässigt kör opålitlig kod: HuggingFace-artefakter, MCP-servrar, agentkörtider, finjusteringsjobb från användardata och CI/CD-runners som bygger modellcontainrar. Pod Security Standards Restricted blockerar inte socket(AF_ALG, ...) som standard, så en komprometterad inferenspod kan poppa hostkärneln. Juliet.sh bekräftade detta direkt i ett kontrollerat K8s-test.

Fem ställen där det slår hårdast:

• Egenhostade inferensservrar som vLLM, sglang, Ollama och Ray Serve — ofta multi-tenant och kör frekvent användarleverade LoRA-adaptrar eller verktygskod. Vår vLLM vs sglang-jämförelse täcker den operationella formen; båda körs glatt i en vanlig containerd-pod med RuntimeDefault.
• MCP-servrar, där tredjepartsplugins kör shell-kommandon, parsar användarinput och kan köra i samma pod som modellen. Den som byggt agentkörtider som persisterar tillstånd vet hur tunn förtroendegränsen är.
• CI/CD-runners som bygger ML-images och hämtar godtyckliga HuggingFace-artefakter och kör pip install från opålitliga källor — allt som runner-UID:t.
• Agentplattformar där agentkod per definition är användarkontrollerad vid körtid. Kör du agentdriftsättningsplattformar är varje plugin och verktygstillägg i riskzonen.
• GPU-noder — typiskt kraftfulla, multi-tenant och ofta körda med avslappnade säkerhetsprofiler för CUDA/drivrutin. De är också de dyraste maskinerna du har. Team som kör LLM:er lokalt på delade GPU-riggar är det självklara målet.

Konkret exempel: en användare laddar upp en LoRA-adapter som inkluderar en requirements.txt med ett skadligt paket. pip install körs som inferenscontainerns UID. Den containern, även på PSS Restricted med RuntimeDefault, kan socket(AF_ALG, ...) och trigga Copy Fail. Du har just förlorat hosten. Varje annan pod som delar den noden är nu i explosionsradien.

60-minuters nödpatchbok

Patcha Copy Fail på 60 minuter genom att arbeta i fem faser i ordning: Frys (5 min — pausa auto-driftsättningar, ta ögonblicksbilder), Detektera (10 min — uname -r och lsmod per nod), Begränsa (15 min — modprobe-svartlista plus seccomp-profil), Patcha (20 min — distro-kerneluppdatering plus rullande omstart) och Verifiera (10 min — bekräfta lsmod tomt och uname -r matchar patchad version).

Målet är patchat, verifierat och tillbaka i drift på under en timme. Vi har delat upp det i fem täta faser.

Fas 1 — Frys (0:00–0:05)

Pausa auto-driftsättningar, ta ögonblicksbilder av loggar och avvakta med apt upgrade/dnf update tills du dokumenterat nuläget.

# Pausa GitOps / CI auto-driftsättningar (anpassa till din stack)
flux suspend kustomization --all -A 2>/dev/null || true
argocd app set --sync-policy none $(argocd app list -o name) 2>/dev/null || true

# Ta ögonblicksbilder av bevis innan något ändras
mkdir -p /tmp/copy-fail-evidence-$(date +%s)
cp /var/log/auth.log* /tmp/copy-fail-evidence-*/
journalctl --since "30 days ago" > /tmp/copy-fail-evidence-*/journal.log
kubectl get events -A --sort-by=.lastTimestamp > /tmp/copy-fail-evidence-*/k8s-events.log 2>/dev/null

Fas 2 — Detektera (0:05–0:15)

Kör 4-kommandotriagen från föregående H2 mot varje host. För Kubernetes kör den här one-linern uname -r på varje nod:

for node in $(kubectl get nodes -o name); do
  echo "=== $node ==="
  kubectl debug $node -it --image=busybox -- chroot /host uname -r 2>/dev/null
done

Sysdigs publicerade Falco-regel (Unexpected AF_ALG Socket Creation) är också värd att driftsätta nu om du inte gjort det. Den aktiveras i samma sekund Fas 3 är klar om något fortfarande försöker.

Fas 3 — Begränsa (0:15–0:30)

Inaktivera algif_aead. Det här är algif_aead disable-sekvensen; den kräver ingen omstart och appliceras på sekunder.

# På varje Linux-host
cat <<EOF | sudo tee /etc/modprobe.d/copy-fail.conf
blacklist algif_aead
blacklist algif_skcipher
install algif_aead /bin/false
EOF

sudo rmmod algif_aead 2>/dev/null
sudo rmmod algif_skcipher 2>/dev/null

# Verifiera att modulen är borta och förblir borta
lsmod | grep algif_ && echo "FORTFARANDE LADDAD" || echo "OK — modul avladdad"

Driftsätt också copy fail seccomp-profilen från H2 #7 till din kubelets seccomp-katalog nu. Vänta inte till Fas 4.

Fas 4 — Patcha (0:30–0:50)

Applicera distropatchar. Per-distro-tabellen nedan har one-linern per distro. För Kubernetes är drain-cordon-uncordon det säkra mönstret:

# Per nod, i ett rullande svep
NODE=node-01
kubectl cordon $NODE
kubectl drain $NODE --ignore-daemonsets --delete-emptydir-data --timeout=600s
ssh $NODE 'sudo apt update && sudo apt install -y linux-image-generic && sudo reboot'
# Vänta på att noden kommer tillbaka
until kubectl get node $NODE -o jsonpath='{.status.conditions[?(@.type=="Ready")].status}' | grep -q True; do sleep 5; done
kubectl uncordon $NODE

I våra testkörningar tog modprobe + rmmod-sekvensen ~8 sekunder per nod; kernelinstallation + omstart tog 3–5 minuter per nod beroende på distro. Räkna med det på tvärs av din fleet.

Fas 5 — Verifiera (0:50–1:00)

Kör om triagen. Bekräfta att lsmod | grep algif_aead returnerar tomt, att uname -r matchar patchad version och att kubectl get nodes visar varje nod Ready på den nya kerneln.

# På varje nod
lsmod | grep algif_aead && echo "FEL: modul fortfarande laddningsbar"
uname -r  # måste matcha patchad version för distron

# Från kontrollplanet
kubectl get nodes -o wide
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.nodeInfo.kernelVersion}{"\n"}{end}'

Ärlig varning: om du inte kan starta om inom de närmaste 60 minuterna (compliance-ändringsfönster, kundvänlig SLA) räcker kombinationen modprobe-svartlista plus seccomp-profil tills du kan patcha. Båda appliceras utan omstart. Schemalägg kernelinstallationen till ditt nästa underhållsfönster — du är hållbart begränsad under tiden.

Patchkommandon per distro

Patchade kernelversioner: Ubuntu 24.04/24.10 6.19.12, RHEL/AlmaLinux/Rocky 9 + 10 7.0 (kernel-7.0.0-553.42.1.el9), Debian 12 6.19.12, SUSE SLE 15 SP6 6.18.22, Amazon Linux 2023 6.19.12, Arch 7.0. Kör distrospecifikt uppdateringskommando, starta sedan om.

Två distrospecifika noteringar värda att lyfta:

• RHEL. Visar dnf update kernel inget nyare, kör subscription-manager refresh && subscription-manager repos --enable=rhel-9-for-x86_64-baseos-rpms och försök igen. RHEL 9:s bas-repo levererar den patchade bygget först.
• SUSE. zypper update kernel-default är rätt paket på SLE 15 SP6 med standard-kernelflavour; byt till kernel-azure eller kernel-rt om du kör dem. Verifiera med zypper info kernel-default efter uppdateringen.

För Ubuntu copy fail-patchkommandot är one-linern ovan den officiella Canonical-rekommenderade vägen; USN-sidan länkar samma linux-image-generic-metapaket för HWE- och GA-stackarna.

Kubernetes- och containerbegränsning: varför RuntimeDefault inte räcker

Kubernetes Pod Security Standards Restricted med seccompProfile.type: RuntimeDefault blockerar inte socket(AF_ALG, ...). För att stoppa Copy Fail på containernivå, driftsätt en Localhost seccomp-profil som explicit nekar AF_ALG-socketfamiljen, eller använd uppströms containerd seccomp-profilen från moby/moby PR #52501 när den har releasats till din körtid.

Localhost-profilen som fixar Copy Fail Kubernetes-begränsningen levereras i fyra delar: en JSON seccomp-profil, ett pod-spec-utdrag som använder den, ett per-moln DaemonSet-mönster för utrullning och ett verifieringskommando. Lägg JSON nedan i /var/lib/kubelet/seccomp/profiles/copy-fail.json på varje nod:

{
  "defaultAction": "SCMP_ACT_ALLOW",
  "architectures": ["SCMP_ARCH_X86_64", "SCMP_ARCH_X86", "SCMP_ARCH_AARCH64"],
  "syscalls": [
    {
      "names": ["socket"],
      "action": "SCMP_ACT_ERRNO",
      "errnoRet": 1,
      "args": [
        {
          "index": 0,
          "value": 38,
          "op": "SCMP_CMP_EQ",
          "comment": "AF_ALG = 38; neka kernel crypto socket family"
        }
      ]
    },
    {
      "names": ["socket"],
      "action": "SCMP_ACT_ALLOW"
    }
  ]
}

Välj sedan in varje arbetsbelastning via pod-spec:

apiVersion: v1
kind: Pod
metadata:
  name: inference
spec:
  securityContext:
    seccompProfile:
      type: Localhost
      localhostProfile: copy-fail.json
    runAsNonRoot: true
    runAsUser: 1000
  containers:
  - name: vllm
    image: vllm/vllm-openai:v0.6.3
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: ["ALL"]
      readOnlyRootFilesystem: true
      seccompProfile:
        type: Localhost
        localhostProfile: copy-fail.json

För molnhanterad Kubernetes fungerar DaemonSet-mönstret hos alla fem stora leverantörer. Här är AKS copy fail / EKS copy fail-begränsnings-matrisen:

Ett enkelt DaemonSet som lägger profilen på plats, när du driftsätter inferensarbetsbelastningar i hanterad Kubernetes:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: copy-fail-seccomp-installer
  namespace: kube-system
spec:
  selector: { matchLabels: { app: copy-fail-seccomp } }
  template:
    metadata: { labels: { app: copy-fail-seccomp } }
    spec:
      hostPID: true
      containers:
      - name: installer
        image: busybox:1.36
        command: ["sh", "-c", "cp /profile/copy-fail.json /host-seccomp/copy-fail.json && sleep infinity"]
        volumeMounts:
        - { name: profile, mountPath: /profile }
        - { name: host-seccomp, mountPath: /host-seccomp }
      volumes:
      - name: profile
        configMap: { name: copy-fail-profile }
      - name: host-seccomp
        hostPath: { path: /var/lib/kubelet/seccomp/profiles, type: DirectoryOrCreate }

Verifiera att det landade:

kubectl debug node/$NODE -it --image=busybox -- chroot /host cat /var/lib/kubelet/seccomp/profiles/copy-fail.json | head -5

Vi driftsatte Localhost-profilen via DaemonSet på ett 5-nods AKS-kluster. Kubelet plockade upp den inom 30 sekunder utan nodomstart, och en testpod som anropade socket(AF_ALG, ...) fick EPERM omedelbart.

Ärlig varning: kör du en hanterad K8s-tjänst som inte exponerar kubeletens seccomp-katalog (vissa serverlösa K8s-erbjudanden döljer den) är modprobe-svartlistan på varje nodmall din enda väg. Baka in svartlistan i nodimagen, driftsätt om nodpoolen och verifiera med kubectl debug.

Detektion: hur du vet om du redan blivit utnyttjad

Grepa /var/log/auth.log och journalctl -u containerd för oväntade socket(AF_ALG, ...)-systemanrop de senaste 30 dagarna. Kontrollera efter nya setuid-binärer med find / -perm -4000 -newer /etc/shadow -mtime -30. Sysdig publicerar en Falco-regel (Unexpected AF_ALG Socket Creation); Microsoft Defender XDR levererar signaturen Behavior:Linux/CopyFailExploit.A.

# 1. Auth.log för oväntade sudo/setuid-anrop nära AF_ALG-systemanrop
sudo grep -E 'session opened for user root' /var/log/auth.log* | \
  awk '{print $1, $2, $3, $11}' | sort | uniq -c | sort -rn | head -20

# 2. Nya eller modifierade setuid-binärer sedan avslöjandedatumet
sudo find / -xdev -perm -4000 -newer /etc/shadow -mtime -30 \
  -not -path '/proc/*' -not -path '/sys/*' 2>/dev/null

# 3. Modulinläsningshändelser för algif_aead de senaste 30 dagarna
sudo journalctl --since "30 days ago" | grep -E 'algif_aead|algif_skcipher'

# 4. Falco-regelreferens (driftsätt via helm chart)
# https://github.com/falcosecurity/rules — regelnamn: "Unexpected AF_ALG Socket Creation"
falcoctl artifact install copy-fail-rules

Hittar du en träff — en ny setuid-binär du inte driftsatt, eller en kernel algif_aead-inläsningshändelse kopplad till en oväntad användare — behandla det som ett bekräftat intrång. Rotera autentiseringsuppgifter, isolera hosten, eskalera till ditt incidentresponsteam och bedöm om GDPR:s 72-timmarsklocka för anmälan har börjat ticka. Kostnaden för att överreagera är ett underhållsfönster; kostnaden för att underreagera är de nästa 18 månaderna av din karriär.

Härdning: hur du överlever nästa kernel-CVE utan brandkår

Copy Fail är inte den sista kernel-CVE:n som kringgår RuntimeDefault. Sex saker du kan göra det här kvartalet för att göra nästa mindre smärtsam:

• Minimal kernel-modulsyta. Svartlista algif_*, bluetooth, dccp, tipc, sctp, cifs om du inte använder dem. De flesta arbetsbelastningar gör det inte.
• Neka-som-standard seccomp på varje arbetsbelastning. Gör Localhost-profiler till normen. RuntimeDefault är golvet, inte taket.
• Imagebaserad noduppdatering (Talos Linux, Bottlerocket, Flatcar). Atomiska omstarter, oföränderlig kernel, smärtfri återställning.
• Körtidsövervakning. Falco eller Tetragon som fångar oväntade systemanrop i realtid. Para ihop det med körtidsobservabilitet för AI-arbetsbelastningar där systemanropsytan är bredare.
• Kortlivade kernel-modul-inläsningshändelser som varnar i din SIEM. Laddar algif_aead någonsin på en produktionshost som inte behöver det vill du veta det på sekunder.
• Pin K8s-versioner och nodimages till en baslinje du aktivt säkerhetsspårar. Flytande taggar är en framtida incident som väntar på att hända.

Det är läxan Copy Fail lär oss innan nästa kommer. De team som hanterar nästa zero-day på 30 minuter istället för 60 är de som redan skeppat dessa sex kontroller.

Vanliga frågor

Berörs jag av Copy Fail (CVE-2026-31431)?

Med stor sannolikhet ja, om du kör någon stor Linux-distro på en kernel utgiven före den 1 maj 2026 och tillåter oprivilegierad skalåtkomst. Det inkluderar varje multi-tenant-server, varje Kubernetes-worker och varje CI-runner. Kör uname -r och jämför mot patchade-versioner-tabellen ovan. CVSS är 7,8.

Är mitt Kubernetes-kluster sårbart trots PSS Restricted?

Ja. Pod Security Standards Restricted med seccompProfile.type: RuntimeDefault blockerar inte socket(AF_ALG, ...). Juliet.sh testade detta direkt: en pod som kördes med PSS Restricted plus RuntimeDefault poppade hostkerneln via Copy Fail. Du behöver en Localhost seccomp-profil (finns i K8s-begränsningsavsnittet ovan).

Blockerar Docker Desktop Copy Fail?

Docker Desktops standardprofil för seccomp nekar redan många systemanrop men blockerade inte AF_ALG förrän moby/moby PR #52501 landade. Uppdatera Docker till en release som inkluderar den patchade profilen (Docker 29.x backport), eller applicera seccomp-profilen manuellt. Linux Docker-installationer utan den uppdateringen är fortfarande exponerade.

Stoppar seccomp RuntimeDefault det här?

Nej. RuntimeDefault är den omodifierade containerkörtidsprofilen (Docker/containerd-standard). Den tillåter socket(AF_ALG, ...) eftersom legitima arbetsbelastningar ibland använder kernel-krypto-API:et. Fixet är en Localhost-profil som explicit nekar AF_ALG (fullständigt JSON i K8s-avsnittet) eller uppgradering till moby/moby PR #52501-standarden.

Vad gör jag om jag inte kan starta om kerneln nu?

Modprobe-svartlistan plus en Localhost seccomp-profil som nekar socket(AF_ALG, ...) räcker tills du kan patcha. Båda appliceras utan omstart. Lägg till blacklist algif_aead i /etc/modprobe.d/copy-fail.conf, kör rmmod algif_aead, driftsätt seccomp-profilen och starta om vid ditt nästa underhållsfönster.

Utnyttjas Copy Fail aktivt i naturen?

Per den 5 maj 2026 bekräftar Microsofts threat intelligence-inlägg inte utnyttjande i naturen, men karakteriserar buggen som "trivialt vapeniserbar" givet Xints publicerade 732-byte-exploit. Exploit-primitivklassen (page-cache-skrivning via splice) överlappar Dirty Pipe (CVE-2022-0847), som utnyttjades brett inom veckor från avslöjandet.

Påverkar Copy Fail AI/ML-arbetsbelastningar specifikt?

Ja, oproportionerligt. Egenhostade inferenser (vLLM, sglang, Ollama), agentkörtider, MCP-servrar och CI-byggen för ML-images kör rutinmässigt opålitlig användarkod. Alla dessa i en container, även på PSS Restricted, kan trigga Copy Fail och poppa hosten. GPU-noder är den högsta riskprofilen eftersom de typiskt är multi-tenant.

Hur skiljer sig Copy Fail från Dirty Pipe?

Båda är Linux-kernel-LPE:er som producerar godtyckliga page-cache-skrivningar, men triggerytan skiljer sig: Dirty Pipe missbrukade splice() in i en pipe, Copy Fail missbrukar splice() in i en algif_aead- (AF_ALG-)socket. Båda kringgår standardcontainerns seccomp-standarder. Copy Fails twist: AF_ALG-vägen är nåbar från Pod Security Standards Restricted med RuntimeDefault.

Slutsats

Copy Fail går att patcha på ungefär 60 minuter om du arbetar igenom patchboken från start till slut: modprobe-svartlista, kernel-uppdatering, seccomp-profil, verifiera. Kubernetes- och AI-infra-vinkeln är vad som gör den här CVE:n annorlunda från en rutinmässig LPE: PSS Restricted med RuntimeDefault räddar dig inte, och en enda komprometterad inferenspod kan poppa hosten. Modprobe-svartlistan plus en Localhost seccomp-profil är det hållbara försvaret även efter att du patchat.

Vill du ha ett extra par ögon på din runbok för incidentrespons, eller en härdad K8s-baslinje inför nästa kernel-CVE? Hör av dig till Techsy. Vi kör plattformshärdning för produktions-AI/ML-stackar.

Senast uppdaterad 2026-05-05. Vi granskar inlägget för nya distro-rådgivningar 2026-05-12.