• Linux-bugg kan ge root-rättigheter och container-utbrytning

    En allvarlig sårbarhet i Linux-kärnans brandväggskod kan låta en vanlig lokal användare få root-rättigheter och i vissa fall bryta sig ut ur en container. Felet, CVE-2026-23111, är redan rättat i Linux-kärnan, men fungerande exploitkod finns nu offentligt dokumenterad. Administratörer bör därför uppdatera kernelpaketen och starta om berörda system snarast.

    Säkerhetsforskare har publicerat en detaljerad och fungerande exploit för en allvarlig sårbarhet i Linux-kärnan. Felet gör det möjligt för en lokal användare utan administratörsrättigheter att höja sina behörigheter till root och i vissa fall bryta sig ut ur en container.

    Sårbarheten har fått beteckningen CVE-2026-23111 och finns i kärnans kod för nf_tables, den moderna delen av Linux brandväggssystem som används av nftables. Felet är en så kallad use-after-free, där minne används efter att det redan har frigjorts. Den typen av buggar kan i värsta fall utnyttjas för att ta kontroll över körningen i kärnan.

    Problemet åtgärdades i Linux-kärnans huvudkod den 5 februari 2026. Trots det har säkerhetsforskare nu publicerat tekniska genomgångar som visar exakt hur sårbarheten kan utnyttjas. Exodus Intelligence publicerade sin detaljerade analys den 8 juni 2026, men redan i april släppte FuzzingLabs en egen reproduktion av felet.

    Enligt beskrivningarna berodde sårbarheten på ett mycket litet programmeringsfel: en felvänd kontroll i nf_tables. Den färdiga korrigeringen i upstream-kärnan bestod i praktiken av en enda rad kod.

    Ubuntu klassar sårbarheten som CVSS 7.8, vilket motsvarar hög allvarlighetsgrad.

    Kräver lokal åtkomst

    Sårbarheten kan inte utnyttjas direkt över nätet. En angripare måste redan ha någon form av lokal åtkomst till systemet, till exempel genom ett kapat användarkonto, ett sårbart programkonto eller en komprometterad container.

    Det som gör buggen särskilt farlig är kombinationen av nf_tables och unprivileged user namespaces. User namespaces är en Linux-funktion som gör att en vanlig användare kan agera som root inne i en isolerad miljö. Funktionen används bland annat av containers och sandbox-lösningar, men har också återkommande varit en väg in till känslig kärnkod.

    På många Linux-installationer, särskilt skrivbordssystem och vissa servermiljöer, är den här kombinationen aktiverad som standard.

    Fungerande root-exploits finns publicerade

    Exodus-forskaren Oliver Sieber, som hittade buggen redan i början av 2025, har visat hur sårbarheten kan kedjas till full lokal root-åtkomst. Exploiten utlöser use-after-free-felet, tar sig förbi flera av Linux-kärnans inbyggda minnesskydd och kapar därefter körningen för att ge angriparen root-rättigheter.

    Exploiten demonstrerades på bland annat:

    • Debian Bookworm
    • Debian Trixie
    • Ubuntu 22.04 LTS
    • Ubuntu 24.04 LTS

    FuzzingLabs har dessutom reproducerat buggen på RHEL 10 inför Pwn2Own Berlin 2026 och byggt en egen root-exploit med en annan teknisk metod.

    Det innebär att tekniken nu är dokumenterad för flera av de största Linux-familjerna: Debian, Ubuntu och Red Hat-baserade system.

    Alla sårbara kärnor bör uppdateras

    Eftersom felet finns i Linux huvudkod kan alla distributioner som har levererat en sårbar kärna vara påverkade, förutsatt att nf_tables och unprivileged user namespaces är aktiverade.

    Det viktigaste rådet är enkelt:

    Uppdatera kärnan och starta om systemet.

    En kerneluppdatering skyddar inte fullt ut förrän datorn eller servern faktiskt har startats om och kör den nya kärnan.

    Ubuntu har enligt uppgifterna rättningar för 22.04 LTS, 24.04 LTS och 25.10. Debian har rättat felet i Bookworm och Trixie, samt tagit fram en 6.1-backport för Bullseye LTS. Även Red Hat, SUSE och Amazon Linux följer sårbarheten i sina respektive säkerhetskanaler.

    Eftersom versionsnumren varierar mellan distributioner bör administratörer kontrollera den egna distributionens säkerhetsmeddelanden och se till att rätt kernelpaket är installerat.

    Tillfällig skyddsåtgärd: begränsa user namespaces

    För system där uppdatering inte kan göras omedelbart kan det vara klokt att se över om vanliga användare verkligen behöver kunna skapa egna user namespaces.

    Att begränsa eller stänga av unprivileged user namespaces kan stoppa just den här angreppsvägen i många miljöer. Det kan dock påverka program som använder sandboxning eller containers, till exempel vissa webbläsare, Flatpak, rootless Podman eller andra isoleringslösningar.

    Det är därför en skyddsåtgärd som bör testas innan den införs brett.

    Del av en större våg av lokala Linux-sårbarheter

    CVE-2026-23111 kommer samtidigt som flera andra lokala root-sårbarheter i Linux har uppmärksammats. Under den senaste tiden har säkerhetsforskare lyft fram bland annat Copy Fail, Dirty Frag, Fragnesia, DirtyDecrypt och en äldre ptrace-sårbarhet som kan läsa /etc/shadow och köra kommandon som root.

    Detaljerna skiljer sig åt, men mönstret är detsamma: en angripare som först får en begränsad lokal åtkomst kan i många fall ta steget vidare till full kontroll över systemet.

    Säkerhetsföretaget Synacktiv har i en genomgång kopplat ökningen av lokala Linux-exploits till bland annat AI-stödd sårbarhetsforskning och snabbare analys av säkerhetspatchar. När en patch väl publiceras kan angripare jämföra ändringen med äldre kod och snabbare förstå hur felet kan utnyttjas.

    Inga kända attacker i det vilda

    Det finns i nuläget inga offentliga rapporter om att CVE-2026-23111 används aktivt i attacker, och ingen känd hotaktör har kopplats till sårbarheten.

    Men exploitkod har varit offentlig sedan april, och en ännu mer detaljerad teknisk genomgång publicerades i juni. Det innebär att organisationer inte bör vänta med att uppdatera.

    För administratörer är prioriteringen tydlig: börja med system där okända eller mindre betrodda användare kan köra kod, där containers används, eller där tjänster kan ge en angripare ett första lokalt fotfäste.

    En lokal sårbarhet är inte ofarlig bara för att den saknar fjärrangrepp. I praktiken är just den här typen av buggar ofta nästa steg efter ett intrång.

    https://thehackernews.com/2026/06/one-character-linux-kernel-flaw-enables.html

    Fakta: CVE-2026-23111

    Sårbarhet: CVE-2026-23111

    Typ: Use-after-free i Linux-kärnans nf_tables-kod

    Påverkar: Linux-system där sårbar kärna, nf_tables och unprivileged user namespaces används

    Risk: Lokal användare kan höja sina rättigheter till root och i vissa fall bryta sig ut ur en container

    Allvarlighet: Ubuntu klassar felet som CVSS 7.8, vilket motsvarar hög allvarlighetsgrad

    Patchad upstream: 5 februari 2026

    Publika exploits: Tekniska genomgångar och fungerande exploits har publicerats av bland annat Exodus Intelligence och FuzzingLabs

    Rekommendation: Uppdatera kärnan och starta om systemet. För system som inte kan uppdateras direkt kan det vara aktuellt att begränsa unprivileged user namespaces, men detta bör testas eftersom det kan påverka containers, Flatpak, rootless Podman och vissa sandboxade program.

  • När Linux sätter gränser för vad som är en säkerhetsbugg

    När antalet AI-genererade sårbarhetsrapporter ökar vill Linuxprojektet dra en tydligare gräns mellan vanliga buggar och verkliga säkerhetshål. Linus Torvalds har nu slagit ihop ny dokumentation som förklarar när ett fel i Linuxkärnan ska behandlas som en säkerhetsbugg, hur rapporter bör skickas in och varför spekulativa AI-fynd inte får belasta säkerhetsteamet i onödan. Resultatet är en mer praktisk hotmodell för Linux – och ett försök att skilja allvarliga angreppsvägar från brus, teorier och dåligt testade rapporter.

    Linuxkärnan är ett av världens viktigaste mjukvaruprojekt. Den används i allt från mobiltelefoner och servrar till routrar, bilar, molntjänster och superdatorer. Därför är frågan om säkerhetsbuggar i Linux inte bara en teknisk detalj för utvecklare, utan något som i förlängningen påverkar stora delar av det digitala samhället.

    Nu har Linus Torvalds slagit ihop ny dokumentation i Linuxkärnan som tydligare förklarar vad som faktiskt räknas som en säkerhetsbugg, hur sådana buggar bör rapporteras och hur utvecklare ska hantera rapporter som tagits fram med hjälp av AI. Dokumentationen ingår i ändringarna för docs-7.1-fixes och bygger bland annat på arbete av Willy Tarreau, känd från HAProxy och underhåll av stabila Linuxkärnor.

    Alla buggar är inte säkerhetshål

    En central poäng i den nya dokumentationen är att inte alla fel i kärnan ska betraktas som säkerhetshål. Linuxprojektet vill i första hand att vanliga buggar ska hanteras öppet, på publika e-postlistor och i den normala utvecklingsprocessen.

    Det finns en praktisk orsak till detta. När fler utvecklare kan läsa, granska och testa en lösning ökar chansen att felet rättas på ett bra sätt. Om en bugg däremot behandlas bakom stängda dörrar av en liten grupp personer finns större risk att viktiga användningsfall missas eller att lösningen inte blir tillräckligt testad.

    Den privata säkerhetslistan är därför tänkt för särskilt allvarliga fall: buggar som är lätta att utnyttja, påverkar många användare och ger en angripare rättigheter som denne inte borde ha på ett korrekt konfigurerat produktionssystem.

    Med andra ord: ett fel blir inte automatiskt ett säkerhetshål bara för att det kan krascha något eller ser farligt ut i teorin. Det avgörande är om felet passerar en verklig säkerhetsgräns.

    Linux får en tydligare hotmodell

    En viktig del av förändringen är att Linuxkärnan nu får en mer uttalad hotmodell. En hotmodell beskriver vad systemet ska skydda mot, men också vad det inte kan eller inte lovar att skydda mot.

    Linuxkärnan ska bland annat skydda användare från varandra på samma system. En vanlig användare ska inte kunna läsa andra användares filer, komma åt deras processminne, spionera på deras processer eller kringgå skydd som styr nätverk och kommunikation.

    Kärnan ska också upprätthålla skydd baserade på så kallade capabilities, alltså särskilda behörigheter som CAP_SYS_ADMIN, CAP_NET_ADMIN och CAP_SYS_PTRACE. En användare utan rätt behörighet ska exempelvis inte kunna ändra nätverksinställningar, manipulera andra användares processer eller påverka kärnans tillstånd.

    Om en bugg gör att en vanlig användare kan få en sådan behörighet, eller göra något som normalt kräver administratörsrättigheter, kan det röra sig om en riktig säkerhetsbugg.

    AI-rapporter har blivit ett problem

    Den nya dokumentationen tar också upp ett modernt problem: AI-assisterade sårbarhetsrapporter.

    AI-verktyg kan vara användbara för att hitta misstänkta buggar i kod, särskilt i gamla eller ovanliga delar av kärnan. Men enligt dokumentationen har många rapporter som skickas till säkerhetsteamet blivit för långa, för spekulativa eller helt enkelt för dåligt verifierade.

    Problemet är inte att AI används. Problemet är när AI-genererade rapporter skickas in utan att någon människa har kontrollerat om felet verkligen går att återskapa, om det har säkerhetspåverkan eller om den föreslagna exploiten faktiskt fungerar.

    Därför säger den nya vägledningen att buggar som hittats med AI normalt ska behandlas som offentliga. Skälet är att flera personer ofta hittar samma typ av AI-upptäckta fel samtidigt. Däremot ska fungerande exploitkod inte publiceras öppet. Rapportören kan i stället säga att en reproducerbar exploit finns och lämna den privat om en ansvarig underhållare ber om det.

    Rapporter ska vara korta, tydliga och testade

    Linuxutvecklarna efterfrågar nu mer disciplinerade rapporter. En bra rapport ska vara kort, skriven i ren text och börja med det viktigaste: vilken fil eller funktion som påverkas, vilka versioner som berörs och vilken konkret påverkan felet har.

    Det räcker inte att skriva att ett fel “kan leda till privilegieeskalering” om det inte är visat. Rapportören bör i stället beskriva vad som faktiskt har testats. Till exempel: kan en vanlig användare få CAP_NET_ADMIN? Kan en process läsa minne den inte ska komma åt? Går felet att återskapa på en normal installation?

    AI-genererade reproducerare ska testas innan de skickas in. Om en AI påstår att en exploit fungerar, men rapportören inte själv har kontrollerat det, riskerar rapporten att ignoreras. Dokumentationen uppmuntrar också till att använda AI för att föreslå och testa fixar, inte bara för att producera fler felrapporter.

    Vad räknas inte som säkerhetsbugg?

    Den nya dokumentationen listar flera typer av problem som normalt inte ska ses som säkerhetshål i Linuxkärnan.

    Det gäller till exempel buggar i gamla, icke-underhållna kärnversioner. Administratörer förväntas hålla sina system uppdaterade, och en sårbarhet måste visas påverka aktivt underhållna versioner för att behandlas som en aktuell säkerhetsfråga.

    Det gäller också osäkra eller ovanliga konfigurationer. Om någon själv har ändrat sysctl-inställningar, filrättigheter eller byggt kärnan med alternativ som uttryckligen sänker säkerheten, är det inte självklart en kärnsårbarhet när något går fel.

    Utvecklingsfunktioner som LOCKDEP, KASAN och FAULT_INJECTION räknas inte heller som produktionsskydd. De är till för testning och felsökning, och kan i sig påverka stabilitet och prestanda.

    Inte heller buggar som kräver orimliga laboratorieförhållanden, modifierad hårdvara, miljarder försök eller redan mycket höga rättigheter ska automatiskt betraktas som säkerhetshål.

    Root som kraschar systemet är inte alltid en sårbarhet

    En annan viktig princip är att åtgärder som kräver full administratörsbehörighet sällan är säkerhetsbuggar i sig. Om root-användaren i den ursprungliga namnrymden kan skriva till en privilegierad enhet och orsaka en kernel oops, är det normalt inte en säkerhetsgräns som brutits. Root hade redan makten att påverka systemet.

    Det Linuxprojektet fokuserar på är i stället när en användare får mer makt än den borde ha. Säkerhetsfrågan uppstår alltså när någon passerar en gräns mellan rättigheter, inte när någon redan har rättigheterna och använder dem på ett destruktivt sätt.

    Användarnamnrymder får särskild förklaring

    Dokumentationen tar även upp CONFIG_USER_NS, alltså stöd för användarnamnrymder. Med denna funktion kan en vanlig användare skapa en isolerad miljö där användaren till synes har fulla rättigheter inom just den miljön.

    Det betyder dock inte att användaren ska kunna påverka hela systemet. En sådan namnrymd får inte ge möjlighet att ändra global systemtid, ladda kärnmoduler, montera blockenheter eller påverka den ursprungliga namnrymden på otillåtet sätt.

    Här blir hotmodellen viktig. En bugg är allvarlig om den gör att isoleringen mellan namnrymder bryts.

    Debuggning är inte alltid tänkt för vanliga användare

    Linux innehåller många kraftfulla verktyg för felsökning och prestandaanalys. Exempel är /proc/kmsg, perf, tracing och debugfs. Dessa kan ge djup insyn i systemet och därmed också bli riskabla om de exponeras fel.

    Den nya dokumentationen betonar att vissa sådana gränssnitt kräver uttryckligt administratörsbeslut. Om en administratör själv ger användare tillgång till känsliga debuggränssnitt är det inte nödvändigtvis ett säkerhetshål i kärnan. Det är en konfigurationsfråga.

    Målet är mindre brus och bättre fixar

    Bakgrunden till förändringen är tydlig: Linuxprojektet vill minska mängden felrapporter som felaktigt märks som säkerhetskritiska. Varje rapport som hamnar fel tar tid från utvecklare och säkerhetsteam. Det gör att verkligt allvarliga problem riskerar att drunkna i brus.

    Samtidigt stänger dokumentationen inte dörren för osäkra fall. Om en rapportör verkligen är osäker på om ett fel är en säkerhetsbugg uppmanas denne fortfarande att rapportera privat. Hellre en extra granskning av ett gränsfall än att en verklig sårbarhet missas.

    Men budskapet är tydligt: kalla inte varje bugg för ett säkerhetshål. Visa vilken säkerhetsgräns som bryts, testa reproduceraren, håll rapporten kort och skicka vanliga buggar till den vanliga utvecklingsprocessen.

    En mognare syn på säkerhet i en AI-tid

    Det här är mer än en intern dokumentationsändring. Det visar hur stora öppna källkodsprojekt anpassar sig till en ny verklighet där AI kan massproducera analyser, hypoteser och rapporter.

    AI kan hjälpa till att hitta riktiga fel. Men den kan också skapa stora mängder halvfärdiga påståenden som människor måste granska. För ett projekt som Linux, där underhållarnas tid är en begränsad resurs, blir kvaliteten på rapporterna avgörande.

    Den nya dokumentationen försöker därför sätta en rimlig balans. Säkerhet ska tas på allvar, men säkerhetsprocessen ska inte överbelastas av spekulationer, dåligt testade AI-fynd eller buggar som egentligen hör hemma i den öppna utvecklingsprocessen.

    I praktiken handlar det om något mycket grundläggande: ett säkerhetshål är inte bara ett fel i kod. Det är ett fel som bryter ett skydd som systemet har lovat att upprätthålla. Linuxprojektets nya dokumentation gör den gränsen tydligare.

    https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=36d49bba19f2c19c933d13b25dcf4eb607a030b3

    Teknisk faktaruta: Linuxkärnans nya säkerhetsdokumentation

    Ämne: Nya riktlinjer för säkerhetsbuggar i Linuxkärnan

    Infört av: Linus Torvalds via dokumentationsändringar i Linuxkärnan

    Pull request: docs-7.1-fixes

    Författare till dokumentationen: Willy Tarreau

    Syfte: Att tydliggöra vad som räknas som en säkerhetsbugg, hur rapporter ska skickas in och hur AI-assisterade buggrapporter ska bedömas.

    Viktiga nyheter:

    • Tydligare gräns mellan vanliga buggar och säkerhetsbuggar.
    • Ny hotmodell för Linuxkärnan.
    • Riktlinjer för AI-genererade och AI-assisterade rapporter.
    • Krav på testade reproducerare och verifierad påverkan.
    • Fokus på buggar som bryter verkliga säkerhetsgränser.

    Exempel på säkerhetspåverkan: En vanlig användare får behörigheter som normalt kräver administratörsrättigheter, exempelvis nätverkskontroll eller åtkomst till andra användares processer.

    Räknas normalt inte som säkerhetsbugg: Fel i gamla kärnversioner, osäkra specialkonfigurationer, utvecklingsfunktioner, teoretiska attacker utan fungerande exploit eller problem som kräver redan höga rättigheter.

    Betydelse: Dokumentationen ska minska brus i säkerhetsrapporteringen och hjälpa utvecklare att fokusera på verkligt allvarliga sårbarheter.

  • Copy Fail: Linux-bugg kan ge vanliga användare root-behörighet

    En ny sårbarhet i Linux-kärnan, kallad Copy Fail, kan göra det möjligt för en vanlig lokal användare att skaffa sig fullständig kontroll över ett system. Felet, som har fått beteckningen CVE-2026-31431, är särskilt allvarligt för servrar, molnmiljöer och plattformar där flera användare eller processer delar samma maskin. En säkerhetsfix finns redan tillgänglig, men administratörer uppmanas att uppdatera och starta om sina system så snart som möjligt.

    En nyupptäckt sårbarhet i Linux-kärnan har fått säkerhetsvärlden att reagera. Felet kallas Copy Fail och har fått beteckningen CVE-2026-31431. Det gör det möjligt för en lokal, obehörig användare att i vissa fall ta full kontroll över ett Linux-system.

    Det handlar alltså inte om ett angrepp som kan göras direkt över internet utan tillgång till datorn. Men om en angripare redan kan köra kod på systemet, till exempel via ett kapat konto, skadlig programvara eller en sårbar applikation, kan felet användas för att höja behörigheten till root.

    Root är den högsta behörighetsnivån i Linux. Den som har root kan i praktiken göra vad som helst: läsa filer, ändra systeminställningar, installera program, skapa nya användare och stänga av säkerhetsfunktioner.

    Fyra byte räcker

    Det som gör Copy Fail särskilt uppseendeväckande är hur litet ingreppet kan vara. Enligt säkerhetsforskarna kan en lokal användare skriva fyra kontrollerade byte till sidcachen, eller page cache, för en fil som användaren kan läsa.

    Page cache är en del av Linux-systemets minne där filer tillfälligt lagras för att systemet ska bli snabbare. I stället för att läsa samma data från hårddisken om och om igen kan Linux hämta den från minnet. Det är normalt en osynlig men viktig prestandafunktion.

    I det här fallet kan angriparen utnyttja ett fel i hur kärnan hanterar kopiering och minne. Genom att påverka innehållet i sidcachen kan angriparen manipulera systemet på ett sätt som i slutänden kan ge root-behörighet.

    Allvarligt för servrar och molnmiljöer

    För vanliga hemanvändare är risken mindre, eftersom angriparen först behöver kunna köra kod lokalt på datorn. Men för miljöer där många användare eller processer delar samma system är hotet betydligt större.

    Särskilt utsatta är:

    • delade Linux-servrar
    • webbhotell och hostingplattformar
    • utvecklingsmiljöer
    • CI/CD-system och byggservrar
    • containerplattformar
    • molnservrar som kör kod från olika kunder eller projekt

    I sådana miljöer kan en till synes begränsad användare eller process bli en väg in till full systemkontroll.

    Offentlig exploit ökar pressen

    Sårbarheten offentliggjordes den 29 april 2026. Enligt uppgifterna finns det redan publik proof-of-concept-kod, alltså demonstrationskod som visar hur felet kan utnyttjas.

    Det gör situationen mer brådskande. När tekniska detaljer och fungerande exempel blir offentliga ökar risken att angripare snabbt bygger egna verktyg för att automatisera attacker.

    Copy Fail har bekräftats på flera stora Linux-distributioner, bland annat:

    • Ubuntu 24.04 LTS
    • Amazon Linux 2023
    • Red Hat Enterprise Linux 10.1
    • SUSE Linux Enterprise Server 16

    Felet ska ha sitt ursprung i en ändring i Linux-kärnan från 2017. Det innebär att den sårbara kodvägen kan ha funnits i många år innan den upptäcktes.

    Uppdatera och starta om

    Den goda nyheten är att en fix redan finns tillgänglig i Linux-kärnan. För administratörer och användare är rådet tydligt: installera de senaste säkerhetsuppdateringarna från den egna Linux-distributionen och starta sedan om systemet så att den nya kärnan faktiskt används.

    Som tillfällig skyddsåtgärd rekommenderar forskarna att den berörda kärnmodulen inaktiveras tills uppdateringar är installerade. För de flesta är dock den säkraste och enklaste vägen att använda distributionens vanliga uppdateringskanaler.

    Därför spelar det här roll

    Copy Fail visar hur sårbarheter i operativsystemets kärna kan få stora konsekvenser även om de inte går att utnyttja direkt på distans. I moderna IT-miljöer är lokal kodkörning ofta bara ett steg i en större attackkedja.

    En angripare som först får begränsad åtkomst kan använda en sådan här sårbarhet för att ta sig hela vägen till administratörsnivå. Därifrån kan intrånget bli betydligt svårare att upptäcka och stoppa.

    För Linux-administratörer är slutsatsen enkel: uppdatera kärnan, starta om systemet och kontrollera att den patchade versionen verkligen körs.

    Teknisk faktaruta

    Copy Fail – CVE-2026-31431

    Typ: Lokal privilegieeskalering i Linux-kärnan

    Påverkan: En lokal, obehörig användare kan i vissa fall få root-behörighet.

    Teknisk detalj: Angriparen kan skriva fyra kontrollerade byte till page cache för en läsbar fil.

    Riskmiljöer: Delade servrar, molnplattformar, CI/CD-system, containerhosts och utvecklingsmiljöer.

    Åtgärd: Installera senaste kerneluppdateringen från distributionens säkerhetskanal och starta om systemet.

    $ sudo apt update && sudo apt full-upgrade
    $ sudo reboot

Etikett: exploit

  • Linux-bugg kan ge root-rättigheter och container-utbrytning

    En allvarlig sårbarhet i Linux-kärnans brandväggskod kan låta en vanlig lokal användare få root-rättigheter och i vissa fall bryta sig ut ur en container. Felet, CVE-2026-23111, är redan rättat i Linux-kärnan, men fungerande exploitkod finns nu offentligt dokumenterad. Administratörer bör därför uppdatera kernelpaketen och starta om berörda system snarast. Säkerhetsforskare har publicerat en detaljerad och…

  • När Linux sätter gränser för vad som är en säkerhetsbugg

    När antalet AI-genererade sårbarhetsrapporter ökar vill Linuxprojektet dra en tydligare gräns mellan vanliga buggar och verkliga säkerhetshål. Linus Torvalds har nu slagit ihop ny dokumentation som förklarar när ett fel i Linuxkärnan ska behandlas som en säkerhetsbugg, hur rapporter bör skickas in och varför spekulativa AI-fynd inte får belasta säkerhetsteamet i onödan. Resultatet är en…

  • Copy Fail: Linux-bugg kan ge vanliga användare root-behörighet

    En ny sårbarhet i Linux-kärnan, kallad Copy Fail, kan göra det möjligt för en vanlig lokal användare att skaffa sig fullständig kontroll över ett system. Felet, som har fått beteckningen CVE-2026-31431, är särskilt allvarligt för servrar, molnmiljöer och plattformar där flera användare eller processer delar samma maskin. En säkerhetsfix finns redan tillgänglig, men administratörer uppmanas…