Två Linuxfel med olika prioritet

Två nyheter från slutet av augusti förändrar prioriteringen för Linuxdrift. Den 27 augusti lade CISA till CVE-2026-53362 i katalogen Known Exploited Vulnerabilities, KEV. En KEV-post betyder att CISA har belägg för verklig exploatering; det är starkare än en teoretisk riskbedömning eller enbart en publicerad teknisk analys. Sårbarheten finns i Linuxkärnans IPv6-hantering och kan låta en lågprivilegierad lokal användare eller process i en container skriva utanför en kärnbuffert, skriva över credentials och nå root på värden.

Den andra sårbarheten, CVE-2026-79619, ligger i OpenZFS för Linux. Där behandlas en capability i en användarskapad, oprivilegierad namnrymd som om den kom från värdens globala namnrymd. En lokal användare kan då nå administrativa ZFS-operationer som normalt kräver root. Canonical klassar felet som High med CVSS 4.0 på 7,3. Vi har inte hittat någon bekräftelse på aktiv exploatering av OpenZFS-felet i de granskade primärkällorna.

LabOps IT klassar därför kärnfelet som Akut och OpenZFS-felet som Hög. De delar en viktig driftmässig nämnare: användarnamnrymder och containrar gör att en till synes lokal sårbarhet kan bli gränsen mellan en begränsad workload och hela värden.

Akut: CVE-2026-53362 kan bryta containergränsen

CVE-2026-53362, även kallad ipv6_frag_escape, är ett fel i funktionen __ip6_append_data(). När ett UDPv6-datagram använder kombinationen MSG_MORE och MSG_SPLICE_PAGES kan kärnan räkna fel på utrymmet för data som flyttas över en fragmentgräns. Resultatet är en kontrollerbar skrivning utanför den allokerade bufferten och in i skb_shared_info.

Red Hat beskriver konsekvensen som godtycklig läsning och skrivning i kärnan, credential-överskrivning, kringgående av SELinux och containerflykt till root på värden. Red Hat klassar sårbarheten som Important och anger CVSS 3.1 på 7,8. Canonical använder prioriteten High och samma CVSS-värde. Angreppsvektorn är lokal, men den praktiska räckvidden är större på fleranvändarsystem och containerplattformar där en angripare redan har kodkörning i en begränsad workload.

CISA:s KEV-post från 27 augusti bekräftar aktiv exploatering och anger 30 augusti som åtgärdsdatum för amerikanska federala myndigheter. Den tidsfristen gäller inte svenska organisationer, men KEV-statusen bör flytta felet från normal patchcykel till incidentnära hantering. De granskade källorna visar en detaljerad offentlig teknisk beskrivning och att en fungerande exploateringskedja har demonstrerats. Vi har däremot inte verifierat att en fristående, allmänt publicerad PoC är tillgänglig; offentlig fungerande PoC ska därför inte anges som bekräftad.

Vilka kärnor och distributioner berörs?

Forskarinformationen anger att de relevanta stabila kärnserierna måste bedömas mot den korrigerande patchen, inte bara mot huvudversionsnumret. Uppströmskorrigeringen för IPv6 är commit 736b380e28d0 i Linux nätverksträd. Distributioner backportar normalt patchen utan att byta huvudversion, så en enkel kontroll som bara jämför uname -r med en internetlista kan ge fel svar. Inventera i stället installerat paket, leverantörens CVE-status och om den specifika backporten ingår.

Canonical angav den 27 augusti bland annat Ubuntu 24.04 LTS med det generiska linux-paketet som sårbart. Ubuntu 26.04 LTS var markerat sårbart med arbete pågående. Ubuntu 22.04 LTS:s standardkärna var inte berörd, men dess HWE 6.8-spår var markerat sårbart. Detta illustrerar varför distributionsvariant och kernel flavour måste finnas i inventeringen.

Red Hats bulletin anger RHEL 10 som direkt berört och att korrigeringar har släppts för alla berörda Red Hat-produkter. OpenShift Container Platform på RHEL 9 anges inte vara påverkat. För RHEL-familjen bör administratören använda leverantörens installerade errata och inte anta att varje 6.12-kärna är sårbar eller korrigerad enbart från versionssträngen.

Den konkreta kontrollen bör omfatta uname -r, pakethanterarens changelog eller advisory-ID, CONFIG_IPV6, möjlighet att skapa användar- och nätverksnamnrymder samt vilka workloads som kan köra egen kod. Prioritera internetexponerade tjänster där ett första intrång i en container skulle kunna kedjas vidare till värden.

Mitigering, patch och driftpåverkan

Den permanenta åtgärden är en distributionskärna som innehåller fixen för CVE-2026-53362, motsvarande uppströmscommit 736b380e28d0. Installera leverantörens säkerhetsuppdatering och planera omstart till den nya kärnan. Kontrollera efter omstart att den aktiva kärnan faktiskt är den uppdaterade; att paketet finns på disk räcker inte. Livepatch får bara räknas som åtgärd när den egna leverantören uttryckligen anger att just denna CVE täcks.

Red Hats tillfälliga mitigering är att stänga av oprivilegierade användarnamnrymder där de inte behövs: sysctl -w user.max_user_namespaces=0. För beständig konfiguration kan värdet läggas i en fil under /etc/sysctl.d/. Detta minskar attackytan men rättar inte kärnfelet. Ändringen kan dessutom stoppa rootless Podman, vissa sandlådor och annan programvara som bygger på user namespaces. Testa därför tjänsterna före bred utrullning och använd patchning som förstahandsval där namnrymder krävs.

Driftpåverkan är främst ett omstartsfönster för kerneluppdateringen och möjlig workload-störning om mitigeringen används. På containerhostar bör evakuering, omstart och återläggning ske nodvis. Följ upp oväntade krascher, kärnvarningar och privilege-förändringar, men betrakta inte frånvaro av sådana indikatorer som bevis på att exploatering inte har skett.

CVE-2026-53362 kedjar en lågprivilegierad process via UDPv6-fragmentering och minneskorruption till kontroll över värdens kärna.

Hög: OpenZFS släppte tre korrigerade grenar

CVE-2026-79619 är en separat felaktig behörighetskontroll i OpenZFS på Linux. Flera ioctl-vägar accepterade CAP_SYS_ADMIN från en användarskapad namnrymd som om capabilityn gällde på värden. Om en lokal användare både kan öppna /dev/zfs och skapa oprivilegierade user namespaces kan användaren nå operationer som pool create, import och destroy, läsa poolens händelselogg och använda fault injection via zinject utan tidigare åtkomst till målpoolen eller dess underliggande enheter.

Canonical klassar sårbarheten som High med CVSS 4.0 på 7,3. Varken Canonicals notis eller OpenZFS versionsinformation bekräftar aktiv exploatering, och vi har inte verifierat en fungerande offentlig PoC. Prioriteten är ändå Hög på fleranvändarvärdar, lagringsservrar och labb där /dev/zfs gjorts åtkomlig för containrar eller lokala operatörskonton. Konsekvensen kan bli otillåten lagringsadministration, dataförlust eller avbrott även utan en fullständig generell root-shell.

OpenZFS publicerade de korrigerade versionerna 2.2.11, 2.3.9 och 2.4.4 den 21 augusti. Ändringarna begränsar de känsliga policykontrollerna till credentials från den globala värdnamnrymden. Använd minst den korrigerade versionen i den gren som distributionen eller produkten stöder; hoppa inte godtyckligt mellan huvudgrenar på en lagringsvärd.

Ubuntu publicerade USN-8705-1 och USN-8705-2 den 31 augusti och markerade den 2 september följande zfs-linux-paket som korrigerade: 2.4.1-1ubuntu5.1 för Ubuntu 26.04 LTS, 2.2.2-0ubuntu9.5 för 24.04 LTS och 2.1.5-1ubuntu6~22.04.7 för 22.04 LTS. Versionsnumren är lägre än OpenZFS uppströms fixgrenar eftersom Canonical backportar patchar. Använd därför distributionens paketversion som facit på Ubuntu.

Som tillfällig riskreduktion kan åtkomsten till /dev/zfs begränsas till strikt nödvändiga rootprocesser och oprivilegierade user namespaces stängas av där de inte behövs. Båda åtgärderna kan bryta avsiktlig delegation, containrar och rootless-arbetsflöden. De är skyddslager, inte ersättningar för ett korrigerat ZFS-paket.

OpenZFS-fixen begränsar känsliga administrativa operationer till credentials från värdens globala namnrymd och stoppar den lokala genvägen.

Prioriterad åtgärdsplan

  1. Akut – hitta CVE-2026-53362-exponering i dag. Lista fysiska och virtuella Linuxvärdar, containerhostar, kernel flavour, aktiv kärna och leverantörens CVE-status. Börja med RHEL 10, Ubuntu 24.04/26.04 och Ubuntu 22.04 med HWE 6.8 enligt de aktuella leverantörsbedömningarna.
  2. Akut – patcha kärnan och starta om kontrollerat. Rulla nodvis där hög tillgänglighet finns. Verifiera aktiv kernel efter omstart och dokumentera vilka noder som inte kan uppdateras.
  3. Akut – mitigera undantag. Om patchfönster saknas, bedöm user.max_user_namespaces=0, segmentera managementnät, minska möjligheten att köra egen kod och övervaka kärnfel tills patchning är genomförd.
  4. Hög – inventera OpenZFS och /dev/zfs. Kontrollera paketversion, enhetsbehörigheter, containermounts och vilka konton som kan skapa user namespaces.
  5. Hög – installera OpenZFS-fixen. Följ distributionspaketet eller uppgradera inom stödd OpenZFS-gren till minst 2.2.11, 2.3.9 eller 2.4.4. Testa poolimport, scrub, snapshot, replikering och bootmiljö efter uppdateringen.
  6. Planerad – återställ temporära begränsningar först efter verifiering. Om user namespaces eller delegationsregler behövs i normal drift ska de återaktiveras stegvis efter att korrigerade paket och regressionskontroller är på plats.

LabOps IT:s bedömning

CVE-2026-53362 är ett bra exempel på varför CVSS inte ensamt kan styra patchkön. Grundpoängen 7,8 beskriver en lokal attack med låg behörighet, men KEV-statusen och möjligheten att lämna en container ändrar den praktiska risken. På en publik containerhost bör felet hanteras som Akut även om den sårbara tjänsten i sig inte kör som root.

OpenZFS-felet har ingen bekräftad aktiv exploatering i våra källor och ska därför inte blandas ihop med KEV-fyndet. Samtidigt skyddar ZFS ofta de data som resten av återställningsplanen förutsätter. Där lokala användare eller workloads når /dev/zfs är Hög prioritet motiverad, särskilt på lagringsservrar som saknar snabb återställning eller separata offlinekopior.

Den viktigaste praktiska slutsatsen är att inventeringen måste beskriva både paket och säkerhetsgränser. Kernelversion, distributionsbackport, user namespaces, containerbehörigheter och enhetsåtkomst avgör tillsammans om en värd är exponerad. Patcha kärnan först, hantera OpenZFS i samma underhållsfönster där det går och verifiera sedan att container-, lagrings- och bootflöden fungerar.

Källor