Dirty Frag är en ny sårbarhet i Linux-kärnan som kan låta en lokal användare eller process höja sina rättigheter till root. Problemet berör bland annat IPsec ESP/XFRM och RxRPC och är särskilt allvarligt på servrar, containerplattformar, CI/CD-runners och andra system där obetrodd kod kan köras. Eftersom publik exempelkod finns tillgänglig bör administratörer uppdatera kärnan och starta om berörda system så snart säkerhetsfixar finns i den egna distributionen.
Kort efter att sårbarheten Copy Fail blev känd har ännu ett allvarligt Linux-problem dykt upp. Den nya sårbarheten kallas Dirty Frag och berör Linux-kärnan, alltså den centrala delen av operativsystemet som styr hårdvara, minne, nätverk och processer.
Dirty Frag är ingen fjärrsårbarhet. Det betyder att en angripare inte kan utnyttja den direkt över internet utan att först ha någon form av lokal åtkomst till systemet. Men på servrar, containermiljöer, CI/CD-system och delade Linux-maskiner kan det ändå vara mycket allvarligt. En vanlig användare, en komprometterad container eller ett byggjobb i en CI-miljö kan i värsta fall höja sina rättigheter och få root-behörighet.
Vad är Dirty Frag?
Dirty Frag är en lokal privilegieeskaleringssårbarhet i Linux-kärnan. Den består egentligen av två närliggande problem:
CVE-2026-43284 berör Linux-kärnans hantering av IPsec ESP/XFRM.
CVE-2026-43500 berör RxRPC, ett protokoll som bland annat används tillsammans med AFS, Andrew File System.
Gemensamt för problemen är att de handlar om hur Linux hanterar sidor i minnet via page cache. Page cache används för att snabba upp åtkomst till filer och data genom att hålla information i minnet. När kärnan hanterar buffertar på fel sätt kan data som egentligen inte ska kunna ändras ändå påverkas.
Det är därför Dirty Frag jämförs med tidigare sårbarheter som Dirty Pipe och Copy Fail. Alla dessa hör hemma i samma bredare familj av problem där felaktig minnes- eller cachehantering kan ge en angripare möjlighet att skriva till data på ett sätt som inte borde vara möjligt.
Varför är detta farligt?
På en vanlig hemdator är risken främst aktuell om någon redan kan köra kod lokalt på datorn. På servrar är situationen annorlunda.
Dirty Frag är särskilt allvarlig i miljöer där många användare, tjänster eller containrar delar samma Linux-kärna. Det gäller till exempel:
- webbhotell
- fleranvändarservrar
- containerhostar
- Kubernetes-noder
- CI/CD-runners
- byggservrar
- system där externa eller mindre betrodda jobb får köras
I sådana miljöer kan en användare eller process som egentligen ska vara begränsad till en låg behörighetsnivå försöka ta sig upp till root. Root är Linux-världens administratörskonto och har i praktiken full kontroll över systemet.
Liknar Copy Fail, men är inte samma sak
Dirty Frag påminner om Copy Fail genom att båda kan leda till lokal root-åtkomst. Men de utnyttjar inte samma kodvägar i kärnan.
Copy Fail påverkade Linux-kärnans kryptodelar via algif_aead.
Dirty Frag berör i stället nätverksrelaterade delar av kärnan, framför allt IPsec ESP/XFRM och RxRPC.
Det gör att Dirty Frag är en separat sårbarhet, även om den tekniskt ligger nära samma typ av page-cache-problem som Copy Fail.
IPsec, ESP och RxRPC – vad betyder det?
IPsec är en teknik för att skydda nätverkstrafik, ofta i samband med VPN-lösningar. ESP står för Encapsulating Security Payload och är en del av IPsec som används för att kryptera och skydda datapaket.
RxRPC är ett protokoll som bland annat används av AFS, ett distribuerat filsystem. Det är inte lika vanligt i vanliga skrivbordsmiljöer, men kan finnas i vissa server- och institutionsmiljöer.
Problemet uppstår när Linux-kärnan hanterar vissa nätverkspaket och sidbaserade buffertar på ett sätt som gör att data kan ändras på plats, trots att bufferten inte borde betraktas som privat för just den operationen.
Förenklat uttryckt: kärnan tror att den får skriva direkt i ett minnesområde, men minnesområdet kan i själva verket delas eller vara kopplat till annan data. Det kan öppna för manipulation av page cache och i förlängningen privilegieeskalering.
Kan Dirty Frag användas för container escape?
Den primära effekten är lokal privilegieeskalering på den sårbara värden. Men i containermiljöer kan problemet bli extra känsligt.
Eftersom containrar delar kärna med värdsystemet kan en sårbarhet i kärnan ibland användas för att bryta sig ut ur containern. Canonical har pekat på att Dirty Frag är relevant i miljöer där containrar kör obetrodda arbetslaster. Det finns dock ingen offentlig container-escape-demonstration som bevisar ett sådant scenario.
Trots det bör containerhostar, Kubernetes-noder och CI-system behandla Dirty Frag som en högprioriterad säkerhetsfråga.
Vilka system påverkas?
Dirty Frag berör flera stora Linuxdistributioner och serverplattformar. Bland de system som uppges vara påverkade finns bland annat Ubuntu, Debian, Red Hat Enterprise Linux, AlmaLinux, openSUSE, SUSE och OpenShift.
Även moderna kärnversioner påverkas, inklusive Linux 7.0 före de korrigerade versionerna. Patchar har börjat dyka upp i nya kärnversioner och i distributionernas egna säkerhetsuppdateringar, men tillgången varierar mellan olika distributioner och versioner.
För administratörer innebär det att man inte bara ska titta på den generella Linux-kärnans versionsnummer, utan också följa den egna distributionens säkerhetsråd. Distributioner bakportar ofta säkerhetsfixar till äldre kärnor utan att byta till en helt ny huvudversion.
Så skyddar man sig
Den rekommenderade lösningen är att installera en uppdaterad kärna från den egna distributionen och sedan starta om systemet. En kärnuppdatering börjar normalt inte skydda systemet fullt ut förrän maskinen faktiskt har startats om med den nya kärnan.
Tillfälliga skyddsåtgärder kan vara att blockera de berörda modulerna om de inte används:
Därefter kan initramfs behöva byggas om:
Om modulerna redan är laddade kan de i vissa fall tas bort med:
Men detta ska göras med försiktighet. Om systemet använder IPsec, strongSwan, Libreswan, AFS, RxRPC eller liknande funktioner kan blockeringen störa nätverk, VPN-anslutningar eller filsystem.
Tillfällig åtgärd är inte samma sak som patch
Att svartlista moduler kan minska attackytan, men det är ingen fullgod ersättning för en riktig säkerhetsuppdatering. Dessutom måste alla berörda delar hanteras. Om bara en av de sårbara komponenterna blockeras kan den andra fortfarande vara exploaterbar.
Därför bör svartlistning främst ses som en tillfällig åtgärd för system där funktionerna inte används. Den långsiktiga lösningen är alltid att installera en korrigerad kärna.
Viktigast för systemadministratörer
Dirty Frag visar ännu en gång varför kärnuppdateringar är kritiska på Linuxsystem. Även om Linux har ett starkt säkerhetsrykte är kärnan mycket komplex, och små fel i minneshantering, nätverkskod eller cachelogik kan få stora konsekvenser.
För vanliga användare är rådet enkelt: installera säkerhetsuppdateringar när de blir tillgängliga och starta om datorn.
För administratörer är rådet mer brådskande: kontrollera vilka system som kör sårbara kärnor, prioritera servrar med flera användare eller obetrodda arbetslaster, uppdatera kärnan, starta om och använd tillfälliga mitigeringar där det är lämpligt.
Dirty Frag är inte en fjärrattack, men i moderna Linuxmiljöer där containrar, automatiserade jobb och delade resurser är vanliga kan en lokal sårbarhet snabbt bli ett allvarligt hot.
https://nvd.nist.gov/vuln/detail/CVE-2026-43284
Teknisk faktaruta: Dirty Frag
Namn: Dirty Frag
Typ: Lokal privilegieeskalering i Linux-kärnan
Risk: En lokal användare, container eller process kan i vissa fall höja sina rättigheter till root.
Berörda områden: IPsec ESP/XFRM och RxRPC
CVE-nummer: CVE-2026-43284 och CVE-2026-43500
Påverkan: Servrar, containerhostar, Kubernetes-noder, CI/CD-runners och delade Linuxsystem är särskilt utsatta.
Inte fjärrkörning: Dirty Frag kräver lokal kodkörning och är inte en direkt fjärrattack över internet.
Rekommenderad åtgärd: Installera uppdaterad Linux-kärna från den egna distributionen och starta om systemet.
Tillfällig mitigering: Blockera modulerna esp4, esp6 och rxrpc om de inte används.
Varning: Att blockera dessa moduler kan påverka IPsec VPN, strongSwan, Libreswan, AFS och andra nätverksfunktioner.
