• DirtyClone: ny Linux-sårbarhet kan ge angripare root-behörighet

    Linuxvärlden har drabbats av ännu en allvarlig kärnsårbarhet. Den nya bristen, kallad DirtyClone, är nära besläktad med DirtyFrag och kan i vissa fall låta en lokal angripare få root-behörighet på sårbara system. Även om felet inte kan utnyttjas direkt på distans är risken betydande, särskilt på system med containrar eller unprivileged user namespaces aktiverade.

    När Linux-administratörer precis börjat lägga DirtyFrag bakom sig dyker nästa besläktade säkerhetsproblem upp. Den nya sårbarheten kallas DirtyClone och har fått beteckningen CVE-2026-43503.

    Det handlar om en allvarlig brist i Linux-kärnan som i vissa fall kan låta en lokal angripare höja sina rättigheter till root. Det betyder att en vanlig användare på systemet, eller någon som lyckats köra kod med låg behörighet, kan få full kontroll över maskinen.

    Inte fjärrstyrd – men ändå allvarlig

    DirtyClone kan inte utnyttjas direkt över internet på samma sätt som en fjärrsårbarhet i en webbserver. Angriparen måste redan ha någon form av lokal åtkomst till systemet.

    Det kan låta som en tröst, men i praktiken är det fortfarande allvarligt. Många attacker sker i flera steg. Först får angriparen in en fot i systemet, till exempel via ett kapat konto, en sårbar tjänst eller en container. Därefter används en lokal sårbarhet för att klättra vidare till administratörsnivå.

    DirtyClone har fått CVSS 8.8, vilket räknas som hög allvarlighetsgrad.

    Vad är det som går fel?

    För att förstå DirtyClone behöver man känna till att Linux-kärnan hanterar nätverkstrafik i små databitar. Dessa ligger i så kallade socket buffers, eller sk_buff.

    Enkelt uttryckt är det små paket med information som kärnan skickar runt internt när nätverkstrafik behandlas.

    Problemet uppstår när vissa delar av kärnan inte bevarar viktig information om hur minnet bakom dessa paket får användas. En särskild markering, som talar om att en minnesbit är delad eller kopplad till filsystemets sidcache, kan tappas bort.

    När den markeringen saknas kan senare kod i kärnan tro att minnet är säkert att skriva till, trots att det egentligen inte borde ändras direkt.

    Resultatet blir att en angripare under rätt omständigheter kan ändra data i Linux sidcache.

    Sidcache – datorns snabba minne för filer

    Linux använder sidcache för att snabba upp filåtkomst. När en fil läses från disk sparas ofta en kopia i RAM-minnet. Nästa gång filen behövs kan systemet läsa den från minnet i stället för från den långsammare disken.

    DirtyClone gör det möjligt att manipulera den här minneskopian av en fil. Det särskilt obehagliga är att angriparen kan påverka innehållet i en root-ägd och skrivskyddad fil i minnet, utan att själva filen på disken ändras.

    Det här påminner om äldre Linux-sårbarheter där skillnaden mellan “det som finns på disk” och “det som just nu finns i minnet” kunnat utnyttjas för att lura systemet.

    Koppling till nätverkskod och IPsec

    DirtyClone finns i Linux-kärnans nätverksdelar. Särskilt nämns kodvägar som rör XFRM/IPsec och hantering av fragment i socket buffers.

    IPsec används bland annat för krypterad nätverkstrafik och VPN-lösningar. XFRM är en del av Linux nätverksstack som hanterar transformering av paket, exempelvis kryptering och dekryptering.

    Sårbarheten blir extra intressant på system där unprivileged user namespaces är aktiverade. Det är en Linux-funktion som gör att vanliga användare kan skapa isolerade miljöer där de får vissa behörigheter som normalt kräver root.

    Det är praktiskt för containrar och sandboxing, men innebär också att sårbarheter i kärnan ibland blir lättare att utnyttja.

    Kan DirtyClone användas för container escape?

    Ja, i vissa scenarier kan DirtyClone eventuellt användas för att ta sig ut ur en container. Det beror på hur systemet är konfigurerat, vilka kernel-funktioner som är tillgängliga och vilka säkerhetslager som används.

    Alla Linux-system är alltså inte lika sårbara. Risken påverkas av flera faktorer:

    • vilken kärnversion som används
    • vilka distributionens patchar som är installerade
    • om unprivileged user namespaces är aktiverat
    • vilka kernel-moduler som är laddade
    • om systemet använder IPsec, RxRPC eller liknande funktioner
    • om extra säkerhet som AppArmor, SELinux eller seccomp används

    Det gör att DirtyClone inte är en enkel “alla Linux-maskiner faller direkt”-sårbarhet. Men den är tillräckligt allvarlig för att tas på största allvar.

    DirtyClone, DirtyFrag och Fragnesia – varför så många namn?

    Namngivningen kan vara förvirrande.

    Sårbarheten är registrerad som CVE-2026-43503. JFrog beskriver exploitvarianten som DirtyClone, medan Ubuntu även använder namnet Fragnesia i sin hantering av problemet.

    Det är alltså inte nödvändigtvis tre helt separata sårbarheter, utan olika namn och perspektiv på samma eller närliggande problemområde i Linux-kärnan.

    DirtyClone hör dessutom till samma familj av buggar som DirtyFrag, men utnyttjar en annan väg genom kärnans nätverkskod. Det visar att tidigare fixar inte helt stängde alla möjliga angreppsvägar.

    Ubuntu, Debian och Red Hat har uppdateringar

    Ubuntu har släppt uppdateringar för flera stödda versioner av sin generiska Linux-kärna.

    För standardkärnan gäller följande fixade versioner:

    Ubuntu-versionFixad kernelversion
    Ubuntu 26.04 LTS7.0.0-22.22
    Ubuntu 25.106.17.0-35.35
    Ubuntu 24.04 LTS6.8.0-124.124
    Ubuntu 22.04 LTS5.15.0-181.191

    Den som kör molnvarianter eller specialkärnor bör kontrollera just sin kernelvariant. Det gäller till exempel AWS, Azure, GCP, Raspberry Pi, realtidskärnor och OEM-kärnor.

    Debian följer också sårbarheten och listar uppdaterade paket för flera grenar, däribland Bullseye, Bookworm och Trixie.

    Red Hat hanterar problemet som en del av DirtyFrag-familjen och beskriver det som lokala sårbarheter i nätverkssubsystemet som kan ge en angripare root-behörighet.

    Vad ska man göra?

    Det viktigaste rådet är enkelt:

    Uppdatera kärnan och starta om datorn.

    Att bara installera kernelpaketet räcker inte. Linux fortsätter nämligen att köra den gamla kärnan tills systemet startas om. Först efter omstart används den uppdaterade och korrigerade kärnan.

    På Ubuntu kan man kontrollera aktuell kärna med:

    uname -r
    

    Efter uppdatering och omstart bör kommandot visa en kernelversion som innehåller fixen.

    Tillfälliga skyddsåtgärder

    Om man inte kan uppdatera direkt finns vissa tillfälliga skydd. Dessa bör dock användas med försiktighet eftersom de kan påverka legitima funktioner.

    Exempel på möjliga åtgärder är att:

    • stänga av unprivileged user namespaces
    • blockera kernelmoduler som esp4, esp6 och rxrpc
    • begränsa användares möjlighet att skapa nätverksrelaterade namespaces
    • förstärka containerprofiler med seccomp, AppArmor eller SELinux

    Men dessa lösningar är inte ersättning för en riktig kerneluppdatering. De är bara tillfälliga hinder.

    Slutsats

    DirtyClone är ännu en påminnelse om att Linux-kärnan är ett mycket komplext system där små detaljer i minneshantering kan få stora säkerhetskonsekvenser.

    Sårbarheten kräver lokal åtkomst, men när den väl kan utnyttjas är konsekvensen allvarlig: en vanlig användare kan i vissa fall bli root.

    För vanliga användare och administratörer är rådet tydligt: installera de senaste säkerhetsuppdateringarna från din Linuxdistribution och starta om systemet.

    Det är först efter omstarten som skyddet faktiskt börjar gälla.

    https://security-tracker.debian.org/tracker/CVE-2026-43503

    https://bugzilla.redhat.com/show_bug.cgi?id=2480902

    Teknisk faktaruta: DirtyClone

    CVE: CVE-2026-43503

    Namn: DirtyClone / Fragnesia

    Allvarlighetsgrad: Hög

    CVSS: 8.8

    Typ: Lokal privilegiehöjning i Linux-kärnan

    Påverkan: Kan ge angripare root-behörighet

    Fjärrutnyttjande: Nej, kräver lokal åtkomst eller möjlighet att köra kod

    Berörd del: Nätverkskod, socket buffer-fragment, XFRM/IPsec

    Extra risk: System med unprivileged user namespaces aktiverade


    Rekommenderad åtgärd:

    Installera senaste kerneluppdateringen från din Linuxdistribution och starta om systemet.

    Viktigt: En kerneluppdatering börjar inte skydda systemet förrän datorn har startats om.

  • OpenZFS 2.4.3: säkrare lagring och stöd för nyare Linux-kärnor

    OpenZFS 2.4.3 är här med bättre stöd för moderna Linux-kärnor, flera viktiga lagringsfixar och skärpt kontroll av komprimerad data. Uppdateringen riktar sig främst till servrar, NAS-system och andra miljöer där ZFS används för säker och pålitlig lagring.

    OpenZFS 2.4.3 har släppts som en ny underhållsversion av det öppna filsystemet och volymhanteraren ZFS. För den vanliga användaren kan versionsnumret låta ganska odramatiskt, men bakom uppdateringen finns flera viktiga förbättringar som gör lagringen stabilare, säkrare och bättre anpassad för moderna Linux- och FreeBSD-system.

    ZFS är mer än bara ett vanligt filsystem. Det är en hel lagringsplattform som kombinerar filsystem, volymhantering, kontrollsummor, snapshots, komprimering och skydd mot datakorruption. Därför används OpenZFS ofta i servrar, NAS-system, backup-lösningar och andra miljöer där dataintegritet är viktig.

    Stöd för Linux-kärnor upp till 7.0

    En av de viktigaste nyheterna i OpenZFS 2.4.3 är förbättrad kompatibilitet med Linux. Den nya versionen stöder Linux-kärnor från 4.18 upp till 7.0. Det betyder att OpenZFS nu kan användas på både äldre företagsdistributioner och nyare system med färska kärnor.

    Detta är särskilt viktigt eftersom ZFS ligger nära operativsystemets kärna. När Linux förändras måste OpenZFS anpassas för att fortsätta fungera korrekt. För användare som kör rullande distributioner, nyare servermiljöer eller testversioner av kommande Linux-kärnor är detta därför en betydelsefull förbättring.

    Även FreeBSD-användare får fortsatt stöd. OpenZFS 2.4.3 är kompatibelt med FreeBSD 13.3 och senare samt FreeBSD 14.0 och senare.

    Flera viktiga lagringsfixar

    OpenZFS 2.4.3 innehåller ett antal korrigeringar som rör själva lagringshanteringen. Bland annat finns förbättringar kring ZVOL, alltså virtuella blockenheter som kan användas ovanpå ZFS. Sådana används ofta för virtuella maskiner, databaser eller andra system som behöver blocklagring i stället för vanliga filer.

    Uppdateringen rättar också problem vid borttagning av loggenheter, så kallade log vdevs. Dessa används för att snabba upp synkrona skrivningar och är vanliga i mer avancerade lagringssystem.

    En annan viktig rättning gäller ett double-free-problem som kunde uppstå med block som klonats efter DDT-pruning. Det är en teknisk detalj, men i praktiken handlar det om att undvika fel i minneshanteringen när ZFS arbetar med deduplicering och blocktabeller.

    Strängare kontroll av komprimerad data

    ZFS har länge varit känt för sin robusta hantering av data. I OpenZFS 2.4.3 skärps kontrollerna ytterligare för komprimerade block. Systemet kontrollerar nu mer exakt att den uppackade datan får rätt längd när algoritmer som lz4, gzip och zstd används.

    Det här är viktigt eftersom komprimering innebär att data lagras i ett mer kompakt format. Om något blir fel vid lagring, läsning eller uppackning måste filsystemet kunna upptäcka det. Strängare kontroller minskar risken för att felaktig eller skadad data passerar obemärkt.

    OpenZFS 2.4.3 lägger även till fler kontroller av storleksfält, textsträngar och så kallade packed nvlists. Det gör systemet bättre på att upptäcka trasiga eller oväntade datastrukturer.

    Förbättringar för Linux-monteringar

    På Linux-sidan finns flera förbättringar kring hur monteringsalternativ hanteras. Det gäller bland annat read/write-flaggor och hanteringen av alternativet source vid montering.

    För användaren märks detta främst som bättre kompatibilitet och mer förutsägbart beteende när ZFS-dataset monteras. I servermiljöer, där monteringar ofta styrs via skript, systemd-enheter eller automatiska rutiner, kan sådana detaljer vara mycket viktiga.

    Versionen innehåller även fixar för äldre Linux-kärnor, bland annat kring fs_parse-API:t i Linux 5.6, samt en byggfix för aarch64. Det senare är viktigt för ARM-baserade system, till exempel vissa servrar, utvecklingskort och NAS-lösningar.

    Bättre verktyg för felsökning

    OpenZFS 2.4.3 förbättrar även verktygen runt filsystemet. Verktyget zdb kan nu upptäcka BRT- och DDT-läckor under blockgenomgång. Det gör det lättare för utvecklare och administratörer att hitta problem i komplexa lagringspooler.

    Även zarcstat har förbättrats. Verktyget kan nu upptäcka en ansluten L2ARC-enhet även om den ännu inte innehåller någon data. L2ARC används som en extra läscache, ofta på SSD, för att snabba upp åtkomst till ofta använd data.

    Färre störningar vid snapshots och NFS

    Snapshots är en av ZFS mest uppskattade funktioner. De gör det möjligt att frysa ett filsystems tillstånd vid en viss tidpunkt, utan att kopiera allt innehåll direkt. Det används ofta för backup, testmiljöer och snabb återställning.

    I OpenZFS 2.4.3 finns en förbättring som gör att systemet undviker att spola bort orelaterade NFS-exporter när en snapshot avmonteras. Det kan minska störningar i miljöer där ZFS används tillsammans med NFS-delningar.

    Versionen rättar också ett problem i hanteringen av PREVIOUSLY_REDACTED, där det sista blocket i vissa fall kunde tappas. Även detta är en detalj som främst berör avancerade ZFS-funktioner, men det visar att uppdateringen fokuserar på stabilitet och datakorrekthet.

    FreeBSD får också förbättringar

    För FreeBSD innehåller OpenZFS 2.4.3 bland annat stöd för att bygga openzfs.ko med sanitizers. Det är verktyg som hjälper utvecklare att hitta fel i koden, till exempel minnesproblem.

    Dessutom finns fixar för kernel panic och cachehantering. Det gör versionen viktig även för FreeBSD-användare, särskilt i server- och lagringsmiljöer där ZFS är vanligt förekommande.

    En underhållsversion som betyder mer än den låter

    OpenZFS 2.4.3 är inte en version fylld med stora nya funktioner för slutanvändare. Det är i stället en typisk underhållsversion: många små och tekniska förbättringar som tillsammans gör systemet säkrare och mer pålitligt.

    För den som använder ZFS i produktion är sådana uppdateringar ofta mycket viktiga. Lagringssystem ska inte vara spännande i vardagen. De ska bara fungera, skydda data och bete sig förutsägbart även när hårdvara, kärnor och operativsystem förändras.

    Med stöd för Linux-kärnor upp till 7.0, förbättrad hantering av monteringsalternativ, striktare kontroller av komprimerad data och flera viktiga lagringsfixar är OpenZFS 2.4.3 en uppdatering som främst handlar om trygghet. Det är kanske inte den mest spektakulära typen av nyhet, men för den som lagrar viktig data är det precis den sortens uppdatering man vill se.

    https://github.com/openzfs/zfs/releases/tag/zfs-2.4.3

    Faktaruta: OpenZFS 2.4.3

    Typ: Underhållsversion av OpenZFS

    Fokus: Stabilitet, säkerhet, kompatibilitet och förbättrad felsökning

    • Stöd för Linux-kärnor 4.18 till 7.0
    • Kompatibelt med FreeBSD 13.3+ och FreeBSD 14.0+
    • Striktare kontroll av uppackad data för lz4, gzip och zstd
    • Ny kontroll av krypteringsnyckel vid blockkloning i ZVOL
    • Fixar för log vdev-borttagning och double-free efter DDT-pruning
    • Förbättrad hantering av ro/rw-monteringar och source-alternativ på Linux
    • Fix för aarch64-byggfel och bättre kompatibilitet med Linux 5.6 fs_parse
    • zdb kan nu upptäcka BRT- och DDT-läckor
    • zarcstat känner nu igen en ansluten L2ARC-enhet även utan data
    • Minskar störningar genom att undvika att spola bort orelaterade NFS-exporter vid snapshot-avmontering
    • FreeBSD får stöd för att bygga openzfs.ko med sanitizers
  • 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.

  • IPFire stärker skyddet mot nya Linux-sårbarheter

    IPFire 2.29 Core Update 202 är en viktig säkerhetsuppdatering för den Linux-baserade brandväggsdistributionen IPFire. Den nya versionen åtgärdar flera aktuella sårbarheter i Linux-kärnan, uppdaterar OpenVPN med stöd för snabbare VPN-trafik och innehåller ett stort antal förbättringar i brandvägg, intrångsskydd, DNS och IPsec. För den som använder IPFire som router, brandvägg eller VPN-gateway är detta en uppdatering som bör installeras snarast.

    Brandväggsdistributionen IPFire har släppts i version 2.29 Core Update 202. Uppdateringen innehåller flera viktiga säkerhetsfixar, ny Linux-kärna, snabbare OpenVPN och ett stort antal uppdaterade systempaket. För den som använder IPFire som router, brandvägg eller VPN-gateway är detta en uppdatering som bör installeras snarast.

    En brandvägg bygger på förtroende

    IPFire är en Linux-baserad brandväggsdistribution som används för att skydda nätverk, styra trafik, köra VPN-tunnlar och hantera intrångsskydd. Eftersom systemet ofta står mellan det interna nätverket och internet är säkerhetsuppdateringar extra viktiga.

    I Core Update 202 ligger fokus framför allt på att täppa till flera aktuella sårbarheter i Linux-kärnan. IPFire har därför uppdaterat sin kärna till Linux 6.18.32. Den nya kärnan rättar bland annat sårbarheterna Dirty Frag och Copy Fail, som båda kan leda till lokal behörighetshöjning.

    Det betyder att en användare som redan har lokal åtkomst till systemet i vissa fall skulle kunna få högre rättigheter, i värsta fall root-behörighet. På en vanlig Linux-server är detta allvarligt. För IPFire är risken i praktiken lägre, eftersom systemet normalt inte är tänkt att ha vanliga användarkonton med skalåtkomst. Vanligen är det bara administratören som har åtkomst till konsolen.

    Men även om angreppsvägen inte är typisk för en brandvägg är uppdateringen viktig. Säkerhet handlar ofta om lager på lager. En sårbarhet som verkar svår att utnyttja i dag kan bli farligare i kombination med andra fel längre fram.

    OpenVPN får rejäl fartökning

    En av de största nyheterna i uppdateringen är att OpenVPN uppdateras till version 2.7.3. Den versionen innehåller stöd för Data Channel Offloading, ofta förkortat DCO.

    Normalt går OpenVPN-trafik genom OpenVPN-processen i användarrymden, där kryptering och dekryptering sker. Med DCO kan en större del av arbetet flyttas ner till Linux-kärnan. Det minskar belastningen på OpenVPN-processen och gör att systemet bättre kan utnyttja hårdvarans stöd för kryptering.

    Enligt IPFire-teamet kan detta ge mycket stora prestandavinster. De rapporterar att VPN-genomströmningen kan öka från omkring 1 Gbit/s till 10 Gbit/s per tunnel, samtidigt som jitter och CPU-belastning minskar.

    För användare med snabba internetförbindelser, flera VPN-tunnlar eller tunga plats-till-plats-kopplingar kan detta vara en av de mest märkbara förbättringarna i uppdateringen.

    Flera nätverksproblem rättade

    Core Update 202 innehåller också flera praktiska fixar i brandväggs- och nätverksfunktionerna.

    Brandväggsregler som använder flera portar i kommaseparerade listor ska nu tillämpas korrekt. Det är en viktig detalj, eftersom små fel i regelhantering kan leda till att trafik antingen blockeras felaktigt eller släpps igenom på ett sätt som administratören inte tänkt sig.

    Intrusion Prevention System, alltså IPFire:s intrångsskydd, har också justerats. Tidigare kunde statistikloggar växa kraftigt och ta upp mycket diskutrymme på vissa system. Uppdateraren tar automatiskt bort de berörda loggarna, och återstående IPS-loggar roteras nu dagligen i stället för veckovis.

    Dessutom får IPFire:s DNS Proxy nu utgående åtkomst utan att administratören behöver skapa extra brandväggsregler. Även IPsec har fått en korrigering där automatiskt skapade brandväggsregler inte alltid togs bort efter att en tunnel stängts ner.

    Viktig fix i glibc

    Uppdateringen innehåller även en säkerhetsfix i glibc, ett av de mest centrala biblioteken i ett Linux-system. Felet gäller hantering av omvänd DNS, där ett specialutformat DNS-svar kunde få funktionerna gethostbyaddr och gethostbyaddr_r att tolka fel del av svaret som giltigt.

    Det kan låta tekniskt, men konsekvensen är viktig: program som använder omvänd DNS för loggning, kontroll eller åtkomstbeslut kan få felaktig information. I säkerhetssammanhang är sådana fel alltid värda att rätta.

    Många uppdaterade systemkomponenter

    Som vanligt med IPFire:s Core Updates innehåller versionen också ett stort antal uppdaterade paket. Bland de viktigare finns:

    • Apache 2.4.67
    • BIND 9.20.22
    • cURL 8.20
    • GnuTLS 3.8.13
    • OpenSSH 10.3p1
    • OpenSSL 3.6.2
    • strongSwan 6.0.6
    • Suricata 8.0.5
    • systemd 260.1
    • Unbound 1.25.1
    • wireguard-tools 1.0.20260223
    • XZ 5.8.3

    Även flera tilläggspaket har uppdaterats, bland annat Samba, HAProxy, Git, Tor, Postfix, rsync, nmap, tshark och Zabbix Agent.

    För Samba nämns dessutom säkerhetsfixar för sårbarheter som rapporterats av en säkerhetsforskare. Det handlar bland annat om brister som kunde göra det möjligt för autentiserade angripare att köra kommandon eller i vissa fall höja sina rättigheter.

    Rekommenderas för alla IPFire-installationer

    IPFire 2.29 Core Update 202 finns tillgänglig för både nya installationer och befintliga system. Nya installationer kan göras på x86_64 och aarch64, medan befintliga system kan uppdateras via IPFire:s webbgränssnitt eller med kommandot pakfire update.

    Efter uppdateringen bör systemet startas om, eftersom den nya Linux-kärnan annars inte börjar användas.

    Slutsats

    IPFire 2.29 Core Update 202 är mer än en vanlig paketuppdatering. Den stärker skyddet mot aktuella Linux-sårbarheter, förbättrar VPN-prestandan kraftigt och rättar flera praktiska problem i brandvägg, IPS, DNS och IPsec.

    För den som använder IPFire i produktion är budskapet tydligt: uppdatera systemet och starta om brandväggen efteråt.

    https://www.ipfire.org/blog/ipfire-2-29-core-update-202-released

    Teknisk faktaruta: IPFire 2.29 Core Update 202

    System: IPFire

    Version: 2.29 Core Update 202

    Typ: Linux-baserad brandväggsdistribution

    Ny Linux-kärna: Linux 6.18.32

    Viktiga säkerhetsfixar: Dirty Frag, Copy Fail och flera andra Linux-sårbarheter

    VPN-nyhet: OpenVPN 2.7.3 med stöd för Data Channel Offloading, DCO

    Förbättring: Högre VPN-prestanda, lägre CPU-belastning och minskat jitter

    Övriga fixar: Brandväggsregler, IPS-loggning, DNS Proxy, IPsec och glibc

    Uppdatering: Kan installeras via IPFire:s webbgränssnitt eller med pakfire

    Rekommendation: Uppdatera snarast och starta om systemet efter installation


  • Dirty Frag: ny Linux-sårbarhet kan ge lokal användare root-behörighet

    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.

  • 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

  • Linux får ett rejält lyft för NTFS – nu med riktigt skrivstöd

    Linux får nu ett kraftigt förbättrat stöd för filsystemet NTFS, som länge varit standard i Windows. Med den nya NTFS-drivrutinen i Linux-kärnan 7.1 blir det möjligt att inte bara läsa utan också skriva fullt ut till NTFS-diskar, samtidigt som prestanda, stabilitet och underhåll förbättras.

    Linux får ett rejält lyft för NTFS – nu med riktigt skrivstöd

    För många datoranvändare är NTFS bara ännu en teknisk förkortning i bakgrunden. Men i praktiken är det ett av världens mest använda filsystem, eftersom det är standard i Windows. Därför är nyheten att Linux-kärnan 7.1 får en ny NTFS-drivrutin med fullständigt skrivstöd större än den först kan verka.

    Det handlar inte bara om att Linux nu kan “läsa och skriva” bättre på Windows-diskar. Det handlar också om snabbare filhantering, bättre stabilitet och modernare kod i själva hjärtat av operativsystemet.

    Vad är NTFS – och varför spelar det roll?

    Ett filsystem är den struktur som avgör hur filer lagras, hittas och organiseras på en hårddisk eller ett USB-minne. Windows använder sedan länge NTFS som sitt huvudsakliga filsystem. Linux använder oftast andra filsystem, som ext4 eller Btrfs, men i vardagen möts systemen ofta.

    Det gäller till exempel när någon kör både Windows och Linux på samma dator, flyttar filer med externa hårddiskar eller USB-minnen, eller arbetar i blandade IT-miljöer där båda systemen används.

    I sådana situationer är det viktigt att Linux kan hantera NTFS-diskar på ett säkert och effektivt sätt.

    Från läsning till full kontroll

    Tidigare har Linux haft begränsat stöd för NTFS i kärnan. Den äldre inbyggda drivrutinen var i praktiken bara för läsning, vilket innebar att användare kunde öppna filer men inte arbeta med dem fullt ut direkt från Linux.

    Nu kommer en ny lösning i Linux 7.1. Den är utvecklad av kärnutvecklaren Namjae Jeon, som beskriver arbetet som resultatet av fyra års utveckling. Målet har varit att skapa en modern NTFS-drivrutin med fullständigt skrivstöd, bättre prestanda, stabilare underhåll och stöd för verktyg i användarutrymmet, bland annat filsystemskontroll.

    Det gör att Linux får betydligt bättre möjligheter att arbeta med NTFS-diskar utan att behöva luta sig mot äldre eller mindre välunderhållna lösningar.

    Vad är det som är nytt?

    Det tekniskt mest betydelsefulla är att den nya drivrutinen inte bara lägger till skrivstöd, utan också bygger på modern Linux-infrastruktur. Bland förbättringarna finns stöd för sådant som iomap, en modern metod för att hantera hur filer kopplas till lagringsutrymme, folio-konvertering som förbättrar hur minnessidor hanteras i kärnan, borttagning av beroendet till buffer_head, en äldre mekanism i Linux, samt stöd för både buffrad och direkt in- och utmatning.

    Översatt till vardagsspråk innebär detta att drivrutinen är bättre anpassad till hur dagens Linux-kärna fungerar. Det gör den både mer framtidssäker och enklare att underhålla.

    Bättre än NTFS3 i tester

    Linux har redan haft en separat NTFS-drivrutin kallad NTFS3, men den nya lösningen verkar ha tagit ett steg framåt i både underhåll och testresultat.

    I de tester som lyfts fram klarade den nya NTFS-drivrutinen 326 xfstests, jämfört med 273 för NTFS3. xfstests är en etablerad testsvit som används för att kontrollera hur väl filsystem beter sig under olika typer av belastning och felhantering.

    Det betyder inte att allt är perfekt, men det tyder på att den nya koden är mer robust och fungerar bättre i fler scenarier.

    Mer än bara läsa och skriva

    Den nya drivrutinen innehåller också stöd för funktioner som fallocate, för effektiv reservering av diskutrymme, idmapped mounts som underlättar modern rättighetshantering, förbättrat stöd för behörigheter och ett nytt verktygspaket i användarutrymmet: ntfsprogs-plus.

    Det sistnämnda är särskilt intressant, eftersom det inkluderar verktyg för fsck-liknande kontroll och reparation av NTFS-filsystem. Med andra ord handlar nyheten inte bara om en drivrutin i kärnan, utan om ett bredare ekosystem för att faktiskt kunna underhålla NTFS-volymer i Linux.

    Varför detta är viktigt för vanliga användare

    Den här typen av nyhet låter lätt som något bara kärnutvecklare bryr sig om. Men i verkligheten påverkar det många fler.

    För en vanlig användare kan förbättrat NTFS-stöd innebära att externa diskar fungerar smidigare mellan Windows och Linux, att dualboot-system blir enklare att använda, att risken för fel minskar vid filöverföring och att Linux blir mer praktiskt i blandade miljöer.

    För administratörer och avancerade användare betyder det också bättre kontroll, bättre verktyg och en mer långsiktig lösning.

    När kommer det?

    Linux-kärnan 7.0 släpptes den 12 april 2026. Om utvecklingen följer det vanliga schemat väntas Linux 7.1 komma någon gång i mitten eller slutet av juni 2026.

    Det innebär att användare sannolikt inte behöver vänta särskilt länge innan den nya NTFS-drivrutinen börjar dyka upp i kommande Linuxdistributioner.

    Ett litet steg i koden – ett stort steg i kompatibilitet

    Den nya NTFS-drivrutinen är ett bra exempel på hur låg nivå i mjukvaruvärlden kan få stor praktisk betydelse. För den som växlar mellan Windows och Linux handlar det om något så enkelt som att filer ska gå att öppna, flytta, redigera och reparera utan problem.

    Men under ytan är det också en berättelse om långsiktigt utvecklingsarbete: fyra år av modernisering, testning och anpassning till dagens Linux-kärna.

    Och just därför är detta mer än bara ännu en teknisk uppdatering. Det är ett steg mot att göra Linux mer användbart i en värld där olika operativsystem hela tiden måste fungera tillsammans.

    Faktaruta: NTFS i Linux 7.1

    Ny drivrutin: Linux 7.1 får en modern NTFS-drivrutin.

    Fullt skrivstöd: Linux kan läsa och skriva till NTFS-volymer mer komplett än tidigare.

    Modern teknik: Bygger på iomap, folio-konvertering och förbättrad minneshantering.

    Testresultat: 326 xfstests godkända, jämfört med 273 för NTFS3.

    Nya funktioner: Stöd för fallocate, idmapped mounts och NTFS-verktyg i användarutrymmet.

    Varför viktigt? Bättre kompatibilitet mellan Linux och Windows i vardaglig användning.

  • Linux 7.1 avvecklar stöd för 486-, 486SX- och AMD Elan-processorer

    I utvecklingsgrenen för Linux 7.1 har x86-koden uppdaterats så att stöd för processorfamiljerna M486, M486SX och AMD Elan tas bort. Ändringen innebär att kärnans lägsta praktiska målplattform för 32-bitars x86 höjs från 486-klass till 586-klass. För dagens användare får detta i stort sett inga praktiska konsekvenser, men tekniskt markerar beslutet ett tydligt steg i den långsamma avvecklingen av mycket gammal PC-hårdvara i Linuxkärnan.

    Stöd för 486-klassen tas bort i x86-koden

    Den aktuella förändringen ingår i en samlad uppdatering av Linuxkärnans x86-plattformskod. I denna uppdatering lyfts borttagandet av stöd för M486, M486SX och MELAN fram som den mest betydande ändringen, före mindre justeringar relaterade till DMI och AMD AGESA.

    Rent tekniskt innebär detta att kärnans konfigurationssystem inte längre erbjuder 486 som giltigt processormål för generiska 32-bitars x86-byggen. I filen arch/x86/Kconfig.cpu har hjälptexten ändrats så att den lägsta breda kompatibilitetsnivån nu anges som 586 i stället för 486. Samtidigt har kommentarerna i samma del av koden uppdaterats för att klargöra att både 386- och 486-baserade system inte längre stöds. AMD Elan nämns också uttryckligen bland de äldre processorfamiljer som nu avvecklas.

    Ändringen gäller inte bara text utan även faktisk konfigurationslogik

    Det handlar inte enbart om språkliga eller dokumentationsmässiga justeringar. De separata konfigurationsalternativen för M486SX, M486 och MELAN har tagits bort ur kärnans Kconfig-struktur. Därmed försvinner också de specifika byggmål som tidigare gjorde det möjligt att anpassa kärnan för dessa processorer.

    Detta är en principiellt viktig detalj. När ett processoralternativ tas bort ur konfigurationssystemet innebär det att kärnan inte längre betraktar denna hårdvaruklass som en aktivt stödd målplattform. I praktiken minskar därmed både testbarhet och möjlighet till formellt underhållet stöd för systemen i fråga.

    Miniminivån höjs från CPU-familj 4 till 5

    Förändringen påverkar också standardvärden och villkorsstyrd logik i den 32-bitars x86-koden. Den lägsta standardnivån för CPU-familj ändras från 4 till 5. Det betyder att baslinjen flyttas från 486-kompatibla processorer till 586-kompatibla processorer.

    I samma arbete har relaterade beroenden och villkor rensats upp för att ta bort hänvisningar till de borttagna alternativen. Denna typ av uppstädning är tekniskt viktig eftersom äldre specialfall annars riskerar att leva kvar i koden och komplicera framtida underhåll, även efter att den egentliga funktionaliteten har tagits bort.

    Begränsad praktisk betydelse för moderna system

    Ur användarperspektiv är den direkta effekten liten. Moderna Linuxdistributioner har sedan länge förutsatt betydligt nyare hårdvara än 486-klassen. Stöd för denna typ av processorer har i praktiken redan varit irrelevant för de flesta vanliga installationer, både på klient- och serversidan.

    Däremot har stödet haft ett symboliskt och teknikhistoriskt värde. Linuxkärnan har länge varit känd för att behålla kompatibilitet med mycket gammal hårdvara, ofta långt efter att annan systemmjukvara har övergett den. Att även 486-klassen nu försvinner visar att även ett projekt med stark tradition av bakåtkompatibilitet till slut måste ompröva nyttan av att bära vidare mycket gamla kodvägar.

    Bakgrunden: långvarig diskussion om nyttan med 486-stöd

    Frågan om att avveckla 486-stödet är inte ny. Linus Torvalds har tidigare offentligt ifrågasatt det praktiska värdet av att behålla denna del av x86-stödet. Resonemanget har i huvudsak varit att koden saknar reell användning i moderna sammanhang och därför inte längre motiverar det underhållsansvar den innebär.

    I ett projekt av Linuxkärnans storlek är detta ett återkommande ingenjörsmässigt avvägningsproblem. Varje kvarvarande stöd för äldre hårdvara medför extra konfigurationsfall, fler beroenden, mer komplex logik och ett större behov av försiktighet vid ändringar i angränsande kod. När användningsvärdet blir tillräckligt lågt blir det tekniskt rationellt att ta bort stödet.

    Samtidiga mindre ändringar i samma x86-uppdatering

    Förutom borttagandet av 486-, 486SX- och AMD Elan-stöd innehåller samma x86-plattformsmerge även två mindre ändringar. Den ena gör det möjligt att skriva ut AGESA-strängen från en post med utökad DMI-information på AMD-baserade system. Den andra består av korrigeringar och generell upprensning i DMI-koden.

    Dessa förändringar är tekniskt relevanta men har inte samma principiella tyngd som höjningen av minimikravet för x86-processorer.

    Ett tydligt generationsskifte i kärnans x86-stöd

    486-processorer tillhör den tidiga 1990-talets PC-generation. Exempel är modeller som Intel 486DX2, en processorfamilj utvecklad före genomslaget för USB, trådlösa nätverk, moderna flertrådade arbetslaster och den typ av grafiskt orienterade Linuxmiljöer som dominerar i dag.

    Att Linuxkärnan under så lång tid har bevarat stöd för denna hårdvaruklass är i sig anmärkningsvärt. Att stödet nu tas bort innebär därför mer än enbart en teknisk förenkling. Det markerar också ett generationsskifte i kärnans syn på vad som ska betraktas som en rimlig lägstanivå inom x86-plattformen.

    Slutsats

    Avvecklingen av stöd för M486, M486SX och AMD Elan i Linux 7.1 är i praktiken en begränsad förändring, men tekniskt tydlig. Kärnans x86-stöd renodlas, minimikravet höjs och äldre specialfall tas bort ur både konfigurationssystem och beroendelogik. För moderna användare är effekten försumbar, men för kärnans arkitektur och historiska utveckling är detta ett tydligt avslut på ännu ett kapitel i Linux långa relation till den tidiga PC-eran.

    Faktaruta

    Linux 7.1: stöd för processorerna 486, 486SX och AMD Elan tas bort ur x86-koden.

    Konsekvens: kärnans lägsta målplattform för 32-bitars x86 flyttas från 486-klass till 586-klass.

    I praktiken: ändringen påverkar nästan inga moderna användare.

    Symboliskt: Linux lämnar ännu en del av den tidiga PC-eran bakom sig.

    Andra artiklar om Linux kernel

  • Fedora 44 försenas – varför några få buggar kan stoppa ett helt operativsystem

    Fedora 44 har försenats efter att flera allvarliga fel upptäckts i systemets mest kritiska delar, som installation, grafik och krypterad uppstart. I stället för att hålla det planerade releasedatumet väljer utvecklarna att pausa lanseringen – ett beslut som visar hur avgörande kvalitetssäkring är när modern programvara ska fungera på många olika typer av hårdvara.

    Det låter kanske dramatiskt: en ny version av Fedora Linux var planerad att släppas den 14 april, men lanseringen stoppades i sista stund. Orsaken? Några envisa fel i systemet – så kallade blocker bugs – som bedömdes vara så allvarliga att hela releasen måste skjutas upp, sannolikt till den 21 april.

    Men varför kan några få buggar få ett helt operativsystem att vänta? Och vad säger det om hur modern programvara faktiskt byggs? Det här är en berättelse om kvalitetskontroll, teknikens komplexitet och varför förseningar ibland är ett tecken på att något fungerar precis som det ska.

    Vad är Fedora – och varför spelar en ny release roll?

    Fedora Linux är en av världens mest inflytelserika Linuxdistributioner. Den används både av entusiaster, utvecklare och som teknikplattform för innovationer som senare kan dyka upp i andra system. Fedora fungerar ofta som ett slags laboratorium för ny programvara: här introduceras nya skrivbordsmiljöer, uppdaterade utvecklarverktyg och modern systemteknik tidigt.

    Version 44 skulle bland annat föra med sig GNOME 50 för Workstation, Plasma 6.6 för KDE-användare, Budgie 10.10 med Wayland-stöd, förbättringar i installationsverktyget Anaconda och flera uppdaterade programpaket för utvecklare och servermiljöer.

    Det är alltså inte konstigt att många väntat på släppet.

    När ett planerat datum inte räcker

    I stora mjukvaruprojekt finns nästan alltid en målkalender. Fedora 44 hade en planerad lansering den 14 april. Men i praktiken är ett releasedatum inte en garanti – det är ett mål som bara gäller om systemet anses tillräckligt stabilt.

    När Fedora-projektet kom fram till att flera allvarliga fel fortfarande var öppna, ställdes det planerade Go/No-Go-mötet i praktiken in. Beskedet från kvalitetsarbetet var tydligt: det fanns flera kvarstående blockerare, och inget tydde på att de kunde ignoreras eller ”viftas bort”.

    Det är här begreppet final blocker bug blir centralt.

    Vad är en blocker bug?

    Alla buggar är inte lika viktiga. Vissa är irriterande men går att leva med, till exempel ett mindre grafiskt fel eller en ovanlig krasch i ett specialprogram. En blocker bug är däremot ett fel som anses så allvarligt att produkten inte bör släppas alls förrän det är löst.

    Det handlar ofta om sådant som:

    • att installationen kraschar
    • att användaren inte kan konfigurera viktiga funktioner
    • att systemet inte startar korrekt
    • att grundläggande säkerhets- eller krypteringsfunktioner fallerar

    Med andra ord: fel som förstör själva grundupplevelsen.

    Vad var det som stoppade Fedora 44?

    De accepterade blockerarna i Fedora 44 rör inte smådetaljer, utan just sådant som användaren möter allra först.

    Ett av problemen gäller en Mesa-bugg som kan få den inledande systemkonfigurationen att krascha på datorer med NVIDIA-hårdvara. Mesa är en viktig del av grafikstacken i Linuxvärlden, och grafikproblem tidigt i uppstart eller installation kan göra systemet oanvändbart direkt för vissa användare.

    De övriga accepterade blockerarna är kopplade till Plasma Setup, alltså installations- och förstagångsflödet för KDE-varianten av Fedora. Där påverkas bland annat tangentbordslayout och Wi-Fi-konfiguration – två saker som är avgörande när en användare ska komma igång med systemet.

    Dessutom finns två föreslagna blockerare kopplade till kärnan, alltså Linux-kärnan själv. De handlar om svart skärm i samband med att användaren anger LUKS-lösenord, alltså lösenordet för krypterade diskar. Ett av fallen ska dessutom vara specifikt observerat på en ThinkPad X1 Carbon Gen 13.

    Detta är ett bra exempel på hur svår modern systemutveckling är: problemen finns i gränssnittet mellan grafikdrivrutiner, kärnan, hårdvara, kryptering och installationsflöden. Ett fel i en sådan kedja kan räcka för att hela upplevelsen faller samman.

    Varför just första uppstarten är så känslig

    Ur ett tekniskt perspektiv är första uppstarten en av de mest kritiska faserna för ett operativsystem. Då ska många delar fungera samtidigt:

    • grafiken ska starta korrekt
    • tangentbord och språkval ska fungera
    • nätverk ska kunna konfigureras
    • krypterade system ska låsas upp
    • användaren ska kunna slutföra grundinställningarna utan fel

    Om något går sönder här spelar det nästan ingen roll hur bra resten av systemet är. Användaren kommer aldrig fram till de mer avancerade funktionerna.

    Det är därför det är logiskt att Fedora väljer att vänta. En release är inte bara en teknisk leverans – den är ett första intryck.

    Förseningen som kvalitetsstämpel

    I teknikvärlden uppfattas förseningar ofta negativt. Men i projekt som Fedora kan en uppskjuten release också tolkas som ett sundhetstecken. Det visar att kvalitetsprocessen faktiskt har mandat att säga stopp.

    Det är frestande att hålla ett datum, särskilt när användare, utvecklare och medier väntar. Men att släppa ett system med kända problem i installation, nätverk eller krypterad uppstart hade sannolikt kostat mer i förtroende än vad en veckas försening gör.

    På så sätt fungerar blocker bugs som en sorts säkerhetsventil i utvecklingsprocessen. De påminner om att programvara inte bara är kod – det är också testning, prioritering och ansvar.

    Vad väntar i Fedora 44 när den väl kommer?

    Trots förseningen ser Fedora 44 ut att bli en stor uppdatering. Bland nyheterna märks:

    • GNOME 50 i Workstation-versionen
    • Plasma 6.6 för KDE-användare, med nytt installationsflöde och ny inloggningshantering
    • Budgie 10.10 med stöd för Wayland
    • förbättringar i Anaconda-installationsprogrammet
    • bättre hantering av Live-media och förbättrat stöd för aarch64 på Windows on ARM-laptops
    • uppdaterade utvecklarverktyg och paket, som MariaDB 11.8, Ansible 13, Helm 4 och Golang 1.26
    • Nix i paketrepositorierna för utvecklare

    Det visar hur bred en modern Linuxrelease är. Det handlar inte bara om ett nytt skrivbord eller några nya appar, utan om ett helt ekosystem av verktyg, drivrutiner, pakethantering och plattformsteknik.

    En liten försening, en stor påminnelse

    Fedora 44:s uppskjutna release är i grunden en påminnelse om hur skör och komplex digital infrastruktur kan vara. Det räcker inte att ”det mesta fungerar”. För ett operativsystem måste även de allra första minuterna – installationen, uppstarten, inloggningen, nätverket – vara robusta.

    Därför är en försenad release ibland bättre än en punktlig.

    Och kanske är det just där den populärvetenskapliga lärdomen finns: bakom varje ”uppdatering” vi klickar hem döljer sig ett enormt samspel mellan människor, kod och maskiner. När det samspelet inte riktigt håller ihop, då märks det direkt. Men när utvecklare vågar bromsa i tid, är det också ett tecken på att tekniken tas på allvar.

    https://qa.fedoraproject.org/blockerbugs/milestone/44/final/buglist

    Teknisk ruta: Fedora 44

    Typ: Linuxdistribution med fokus på ny teknik och snabba uppdateringar

    Status: Försenad release på grund av kvarvarande blocker bugs i kritiska systemdelar

    Planerat släpp: Flyttat från 14 april till tidigast 21 april

    Berörda problem: krascher i initial setup på NVIDIA-system, fel i Plasma Setup för tangentbord och Wi-Fi samt svarta skärmar vid LUKS-upplåsning

    Skrivbordsmiljöer: GNOME 50, Plasma 6.6 och Budgie 10.10 med Wayland-stöd

    Övriga nyheter: uppdaterad Anaconda-installation, förbättrad Live-media, bättre stöd för aarch64 på Windows on ARM samt nya paketversioner för utvecklare

    Exempel på uppdaterade verktyg: MariaDB 11.8, Ansible 13, Helm 4 och Golang 1.26

  • Linux From Scratch 13.0 släppt – bygg ditt eget Linux från grunden

    Linux From Scratch har släppt version 13.0 av sin välkända guide för att bygga ett komplett Linux-system från källkod. Den nya utgåvan innebär flera viktiga förändringar, bland annat att projektet nu helt överger SysVinit och enbart erbjuder en systemd-baserad version, samtidigt som ett stort antal centrala komponenter har uppdaterats.

    Linuxvärlden domineras i dag av färdiga distributioner som Ubuntu, Fedora och Debian. Men det finns också ett projekt som tar ett helt annat grepp: Linux From Scratch (LFS). I stället för att installera ett färdigt system får användaren här instruktioner för att själv bygga upp hela operativsystemet från grunden.

    LFS är egentligen inte en distribution utan en bok och ett projekt som steg för steg visar hur man laddar ner, kompilerar och installerar alla delar som behövs för ett fungerande Linux-system. Resultatet blir ett minimalt men fullt fungerande system där användaren själv har kontroll över varje komponent.

    Nu endast systemd

    En av de största förändringarna i LFS 13.0 är att projektet nu helt överger den klassiska init-lösningen SysVinit. Tidigare versioner av guiden fanns i två varianter: en med SysVinit och en med systemd.

    I den nya versionen finns endast systemd-utgåvan kvar.

    Beslutet motiveras främst av underhållsskäl. Allt fler moderna program förutsätter systemd eller använder funktioner som är tätt integrerade med systemet. Genom att fokusera på en enda init-lösning hoppas utvecklarna kunna hålla dokumentationen enklare och mer aktuell.

    Uppdaterade kärnkomponenter

    LFS 13.0 innehåller också flera uppdateringar av centrala systemkomponenter. Bland de viktigaste finns:

    • binutils 2.46
    • glibc 2.42
    • Linux-kärnan 6.18.10 LTS

    Totalt har 36 paket uppdaterats jämfört med föregående stabila version. Det innebär att instruktionerna i boken nu speglar en modern Linux-miljö och gör det möjligt att bygga ett system baserat på aktuella verktyg och bibliotek.

    Över 100 ändringar i boken

    Sedan den senaste stabila utgåvan har utvecklarna gjort över 100 ändringar i LFS-boken. En stor del av arbetet har handlat om säkerhetsuppdateringar.

    Bland de program som fått säkerhetsrelaterade uppdateringar finns:

    • glibc
    • coreutils
    • expat
    • Perl
    • Python
    • systemd
    • xz
    • Vim

    Det gör att den nya versionen inte bara är modernare utan också bättre rustad ur säkerhetssynpunkt.

    Beyond Linux From Scratch kompletterar systemet

    Samtidigt som LFS 13.0 släpptes publicerades även Beyond Linux From Scratch (BLFS) 13.0. Medan LFS beskriver hur man bygger ett grundläggande Linux-system, går BLFS betydligt längre.

    BLFS innehåller instruktioner för hur man installerar hundratals extra program och bibliotek, bland annat skrivbordsmiljöer som GNOME, KDE Plasma, XFCE och LXQt, samt vanliga program som webbläsare, e-postklienter och kontorsprogram.

    Tillsammans gör LFS och BLFS det möjligt att steg för steg bygga upp ett komplett Linux-system – från kärnan till ett fullt grafiskt skrivbord.

    Ett projekt för den nyfikne

    Linux From Scratch är inte tänkt för nybörjare som bara vill installera ett operativsystem snabbt. I stället riktar det sig till entusiaster, utvecklare och studenter som vill förstå hur Linux verkligen fungerar bakom kulisserna.

    Genom att själv kompilera varje komponent – från kompilatorn till systembiblioteken – får man en unik inblick i hur ett modernt operativsystem byggs upp.

    För många fungerar LFS därför både som ett utbildningsprojekt och en experimentplattform där man kan lära sig mer om Linux än vad en vanlig distribution normalt visar.

    https://linuxfromscratch.org/blfs/view/13.0-systemd

    Fakta: Linux From Scratch 13.0

    Typ: Bok och projekt för att bygga Linux från källkod

    Ny version: LFS 13.0

    Init-system: Endast systemd

    Tidigare stöd: SysVinit har tagits bort

    Viktiga komponenter: binutils 2.46, glibc 2.42, Linux 6.18.10 LTS

    Antal uppdaterade paket: 36

    Komplettering: BLFS 13.0 ger stöd för bland annat GNOME, KDE Plasma, XFCE och LXQt

  • GNU Hurd tar steget in i 64-bitarsvärlden

    GNU Hurd har tagit ett historiskt steg in i 64-bitarsvärlden. Efter över tre decennier som ett experimentellt 32-bitarsprojekt kan den alternativa GNU-kärnan nu köras nativt på modern x86_64-hårdvara – tack vare integrationen i GNU Guix. Det innebär inte att Hurd ersätter Linux, men det gör projektet tekniskt relevant igen och öppnar dörren för en ny generation utvecklare och forskare.

    Efter mer än tre decennier av utveckling har GNU Hurd fått inbyggt stöd för x86_64-arkitekturen. Det innebär att systemet nu kan köras nativt på modern 64-bitars hårdvara. Stödet levereras via GNU Guix, som både är en avancerad pakethanterare och ett komplett operativsystem.

    Detta markerar första gången Hurd officiellt lämnar sin 32-bitarsbegränsning bakom sig.

    Vad är GNU Hurd?

    Hurd är tänkt att vara kärnan i det operativsystem som utvecklas av GNU Project. Projektet startade redan på 1980-talet med målet att skapa ett helt fritt operativsystem. När Linux dök upp i början av 1990-talet blev det snabbt den praktiska kärnan i GNU/Linux-systemen, medan Hurd fortsatte som ett mer experimentellt alternativ.

    Till skillnad från Linux bygger Hurd på en mikrokärnearkitektur baserad på GNU Mach. I en sådan design är själva kärnan minimal. Funktioner som filsystem, nätverk och enhetsdrivrutiner körs som separata servrar i användarrymden och kommunicerar genom meddelanden.

    Tanken är att detta ska ge större flexibilitet, bättre modularitet och potentiellt högre säkerhet. I praktiken har det också inneburit tekniska utmaningar som gjort utvecklingen långsam.

    Varför är 64-bitarsstöd så betydelsefullt?

    Under lång tid var Hurd begränsat till 32-bitars x86-system. Det innebar att:

    • Minne var begränsat till maximalt 4 GB adresserbart utrymme
    • Modern hårdvara inte kunde utnyttjas fullt ut
    • Projektets praktiska användbarhet minskade

    Med x86_64-stöd kan Hurd nu använda betydligt större minnesutrymmen och köras direkt på dagens processorer utan kompatibilitetslager. Det gör systemet mer relevant för forskning och utveckling.

    Det betyder dock inte att Hurd plötsligt blir ett alternativ till etablerade system. Snarare handlar det om att ta bort en teknisk spärr som länge hållit projektet tillbaka.

    GNU Guix och den nya generationens systembygge

    Det är genom Guix som 64-bitarsversionen nu görs tillgänglig. Guix är både en pakethanterare som kan installeras ovanpå andra Linux-system och en fullständig distribution kallad Guix System.

    En central idé är att hela systemet definieras deklarativt som kod. Det innebär att:

    • Uppdateringar sker atomiskt
    • Tidigare systemtillstånd kan återställas
    • System kan reproduceras exakt på flera maskiner

    I den senaste versionen har projektet lagt till över 12 000 nya paket och genomfört tiotusentals uppdateringar. Centrala verktyg och kompilatorer har moderniserats, och systemhanteringen har förbättrats med nya tjänster och säkerhetsfunktioner.

    Samtidigt fortsätter arbetet med att minimera beroendet av förkompilerad kod, vilket är en viktig del av projektets ambition att bygga systemet helt från källkod.

    Experimentellt – men inte irrelevant

    Trots framstegen är GNU Hurd fortfarande experimentellt. Hårdvarustödet är begränsat och stabiliteten når inte upp till nivåerna hos mer etablerade kärnor. Det är inte avsett för produktionsmiljöer.

    Men 64-bitarsstödet gör systemet mer tillgängligt för:

    • Operativsystemforskning
    • Säkerhetsstudier
    • Arkitekturexperiment
    • Fri programvaruutveckling

    Det blir nu möjligt att testa och utveckla Hurd på vanlig modern utrustning i stället för att förlita sig på äldre 32-bitarsmaskiner.

    En symbol för uthållighet

    Att Hurd nu tar klivet in i 64-bitarsvärlden är mer än en teknisk uppdatering. Det är ett tecken på långsiktig envishet inom fri programvaruvärld. I en bransch där många projekt försvinner efter några år har Hurd fortsatt att utvecklas i över 30 år.

    Det återstår att se vilken roll systemet kommer att spela i framtiden. Men med stöd för modern arkitektur har GNU Hurd tagit ett steg från historisk kuriositet till ett återigen relevant forskningsprojekt.

    https://guix.gnu.org/blog/2026/the-64-bit-hurd

    Faktaruta: GNU Hurd 64-bit via Guix

    Kort sagt: GNU Hurd har nu nativt x86_64-stöd som kan testas via GNU Guix/Guix System.
    Vad är Hurd? En experimentell GNU-kärna byggd ovanpå mikrokärnan GNU Mach, där flera systemtjänster körs som separata servrar i användarrymden.
    Varför 64-bit spelar roll: Modern hårdvara och större minnesadressrymd (praktiskt för utveckling, test och forskning).
    Hur får man tag på det? Guix tillhandahåller systemavbildningar/verktyg för installation eller test.
    Viktigt: Hurd är fortfarande experimentellt och inte ett produktionsalternativ till Linux.
  • Kan artificiell intelligens få en plats i Linux-kärnan?

    Kan Linux-kärnan bli smartare med hjälp av artificiell intelligens?
    En ny diskussion bland Linux-utvecklare väcker frågan om maskininlärning kan användas för att optimera hur operativsystemets innersta delar fungerar. Förslaget är försiktigt, kontroversiellt – och helt utanför kärnan själv.

    Tänk dig att Linux-kärnan – själva hjärtat i operativsystemet – kunde lära sig av sitt eget beteende och fatta smartare beslut i realtid. Det är precis den sortens framtid som nu diskuteras bland Linux-utvecklare.

    På Linux kernel mailing list (LKML), den centrala mötesplatsen för kärnutveckling, har en ny idé väckt uppmärksamhet: att låta maskininlärning hjälpa vissa delar av kärnan att fungera bättre. Förslaget kommer från Viacheslav Dubeyko, ingenjör på IBM, och handlar om att skapa en generell infrastruktur där kärnans olika delsystem kan samarbeta med maskininlärningsmodeller – utan att dessa modeller körs i själva kärnan.

    Maskininlärning – men utanför kärnan

    En viktig poäng i förslaget är att all maskininlärning ska ske helt i användarutrymmet (user space), inte inne i kärnan. Det är ett medvetet och strategiskt val. Linux-kärnan är extremt känslig för instabilitet, fördröjningar och säkerhetsproblem. Att köra stora och komplexa ML-ramverk där vore både riskabelt och svårt att acceptera för kärnans utvecklare.

    I stället föreslås ett slags kommunikationslager. Kärnan kan skicka mätdata och statusinformation till en användarprocess som kör en maskininlärningsmodell. Modellen analyserar informationen och skickar tillbaka rekommendationer eller förslag, som kärnan kan välja att använda – eller ignorera.

    Vad skulle ML kunna bidra med?

    Diskussionen handlar inte om självlärande operativsystem i science-fiction-stil, utan om ganska konkreta problem. Exempel som nämns är:

    • schemaläggning av processer
    • minneshantering
    • optimering av I/O-prestanda
    • att förutse belastningstoppar eller flaskhalsar

    I dag bygger dessa delar ofta på statiska algoritmer och handskrivna heuristiker. Tanken är att maskininlärning i vissa fall skulle kunna anpassa sig bättre till verkliga användningsmönster och föränderliga arbetslaster.

    Skepsis och försiktighet

    Som väntat har förslaget mötts av både nyfikenhet och skepticism. Linux-kärnans utvecklare är kända för sin försiktiga hållning, och flera frågor är fortfarande obesvarade:

    • Hur säkerställer man att ML-baserade rekommendationer inte försämrar stabiliteten?
    • Vad händer om modellen ger felaktiga råd?
    • Är den potentiella vinsten värd den ökade komplexiteten?
    • Hur testar man system som inte alltid beter sig deterministiskt?

    Det är därför arbetet fortfarande är tydligt experimentellt. De föreslagna patcharna har inte accepterats i huvudgrenen av Linux-kärnan, och ingen talar ännu om detta som något som är på väg in i vanliga Linux-system.

    Ett försiktigt steg mot framtiden

    Oavsett om ML-assisterade kärndelsystem blir framtid eller bara ett intressant experiment, visar diskussionen att även ett av världens mest konservativa och stabilitetsfokuserade mjukvaruprojekt utforskar nya idéer.

    Om maskininlärning någon gång blir en naturlig del av Linux-kärnans beslutsfattande återstår att se. Men just nu är frågan inte längre om den diskuteras – utan hur långt den kan tillåtas gå.

    FAKTARUTA / Linux-kärnan & maskininlärning
    • Idé: Låta kernel-delsystem få “råd” från ML-modeller.
    • Upplägg: ML körs helt i user space – inte i kärnan.
    • Förslag: En generell infrastruktur som kopplar kärnan till användarprocesser som kör modeller.
    • Status: Explorativt – patcharna är inte mergade i mainline.
    • Frågetecken: Säkerhet, determinism, testbarhet och faktisk nytta.
    $ Det återstår att se om ML-stöd i kärnans ekosystem blir mer än experiment.
  • Debian 13.3 är här – stabilitet före allt annat

    Debian fortsätter att finslipa sin senaste stabila version. Med Debian 13.3 samlas månader av säkerhetsuppdateringar och buggfixar i en ny punktrelease som gör systemet tryggare, stabilare och enklare att installera på ny hårdvara – utan att ändra det som redan fungerar.

    Två månader efter föregående uppdatering har Debian Project släppt Debian 13.3, den tredje punktuppdateringen i Debian GNU/Linux 13 ”Trixie”-serien. Det är inte en version som introducerar nya funktioner. I stället handlar den, helt i linje med Debians filosofi, om att göra systemet säkrare, stabilare och mer tillförlitligt.

    Vad är egentligen en punktuppdatering?

    Debians punktuppdateringar samlar redan släppta säkerhetsfixar och bugg­rättningar i nya installationsavbilder. För användare som kontinuerligt uppdaterar sina system via security.debian.org innebär Debian 13.3 därför inga större förändringar i praktiken. För nya installationer är nyttan däremot tydlig: systemet är i stort sett helt uppdaterat redan från start, utan behov av att ladda ner hundratals paket direkt efter installationen.

    Säkerhet och kvalitet i fokus

    Debian 13.3 innehåller totalt 108 buggfixar och 37 säkerhetsuppdateringar. Bland de uppdaterade paketen återfinns många centrala komponenter i moderna Linux-system, däribland Ansible, Apache2, Flatpak, Go-relaterade verktyg, PostgreSQL 17, QEMU och Linux-kärnan.

    Säkerhetsfixarna åtgärdar bland annat heltalsöverflöden, tolkningsfel, heap-överflöden, minneskorruption, överbelastningsattacker och gränskontrollfel. Även grundläggande bibliotek som glibc och glib2.0 har fått viktiga korrigeringar, liksom skrivbordsmiljöer och välkända program som GNOME Shell, Thunderbird, Chromium och VLC.

    Förbättrat hårdvarustöd och installerare

    Utöver programuppdateringar innehåller Debian 13.3 även uppdaterad mikrokod för Intel-processorer, justeringar i installationskomponenterna samt en höjd kernel-ABI. Alla ändringar har byggts om mot föreslagna uppdateringar för att säkerställa maximal kompatibilitet och stabilitet.

    Debian Installer har samtidigt uppdaterats för att inkludera samtliga korrigeringar från denna punktrelease. Det innebär att nya installationer av Debian 13 startar i ett fullt uppdaterat och säkert läge.

    Brett stöd för arkitekturer

    Debian 13.3 finns tillgänglig för sex olika hårdvaruarkitekturer: amd64, arm64, armhf, ppc64el, riscv64 och s390x. För den som vill ha ett mer färdigt system finns även Live-avbilder med förinstallerade skrivbordsmiljöer som GNOME, KDE Plasma, Xfce, Cinnamon, MATE, LXQt och LXDE. Dessa Live-versioner är tillgängliga för amd64.

    Även Debian 12 uppdateras

    Samtidigt har Debian-projektet släppt Debian 12.13 för den äldre stabila serien ”Bookworm”. Denna uppdatering innehåller 96 buggfixar och 85 säkerhetsuppdateringar. Precis som med Debian 13.3 handlar det om samlade korrigeringar, utan nya funktioner, och uppdateringarna distribueras via vanliga Debian-speglar.

    Så uppdaterar du ditt system

    Befintliga användare av Debian 13 behöver endast köra följande kommando för att uppdatera till senaste stabila version:

    sudo apt update && sudo apt full-upgrade

    Alternativt kan en grafisk pakethanterare, exempelvis Synaptic, användas.

    Slutsats

    Debian 13.3 är ännu ett exempel på Debians långsiktiga fokus på stabilitet och säkerhet. Inga snabba nyheter, inga experimentella funktioner – bara noggrant testade förbättringar som gör systemet tryggare att använda. För nya installationer är Debian 13.3 den rekommenderade versionen, och för befintliga användare är uppdateringen en självklar del av ett välskött system.

    https://www.debian.org

    Mer information om Debian och med länkar ifrån vilken FTP man kan tanka den ifrån finner du i vår Wiki

    https://wiki.linux.se/index.php/Debian

    FAKTARUTA: Debian 13.3 & Debian 12.13
    Debian 13.3 är den tredje punktuppdateringen för stabila Debian 13 “Trixie”. Inga nya funktioner – fokus ligger på samlade säkerhetsfixar och buggfixar samt uppdaterade installationsavbilder.
    • Debian 13.3: 108 buggfixar + 37 säkerhetsuppdateringar
    • Större uppdateringar: Ansible, Apache2, Flatpak, Go-komponenter, PostgreSQL 17, QEMU, Linux-kärnan
    • Viktiga fixar: glibc, glib2.0, GNOME Shell, Thunderbird, Chromium, VLC
    • Hårdvara/installerare: uppdaterad Intel-mikrokod + uppfräschad Debian Installer
    • ISO-stöd: amd64, arm64, armhf, ppc64el, riscv64, s390x (Live-images för amd64)
    • Debian 12.13 (Bookworm): 96 buggfixar + 85 säkerhetsuppdateringar
    Uppdatera befintligt system
    sudo apt update && sudo apt full-upgrade
  • Debian gör loong64 till officiellt stödd arkitektur i Debian 14

    När Debian officiellt gör loong64 till en fullt stödd arkitektur tas ett historiskt steg för både projektet och den kinesiska processorplattformen LoongArch. Efter mer än två års arbete i Debian Ports är loong64 nu på väg in i huvudutgåvan Debian 14 Forky, där den kommer att omfattas av samma byggsystem, säkerhetsuppdateringar och långsiktiga stöd som Debians övriga arkitekturer. Beslutet markerar inte bara teknisk mognad, utan också Debians fortsatta ambition att stödja öppna och alternativa hårdvaruplattformar på global nivå.

    Efter drygt två års arbete har Debian officiellt befordrat arkitekturen loong64 från Debian Ports till fullvärdig, stödd arkitektur. Om det återstående integrationsarbetet fortlöper enligt plan kommer loong64 att ingå i den kommande versionen Debian 14, med kodnamnet Forky.

    Beskedet offentliggjordes på e-postlistan debian-devel-announce. Med officiell status följer loong64 nu samma bygg-, release- och säkerhetsprocesser som Debians övriga huvudarkitekturer.

    Vad är loong64

    Loong64 är 64-bitarsvarianten av instruktionsuppsättningen LoongArch, som utvecklas av det kinesiska företaget Loongson. Arkitekturen är framtagen som ett alternativ till etablerade plattformar som x86 och ARM, med fokus på teknologisk självständighet.

    Genom Debians officiella stöd får LoongArch-baserade system tillgång till ett stort, väletablerat ekosystem av fri programvara.

    Så gick uppstarten till

    Arbetet med loong64 inleddes i Debian Ports, där nya och experimentella arkitekturer utvecklas. För att komma igång krävdes ett manuellt grundarbete. Totalt byggdes och importerades 112 paket, vilket var tillräckligt för att skapa en fungerande chroot-miljö och sätta den första automatiska byggservern, en så kallad buildd, i drift.

    Redan under sin första natt byggde och laddade denna enda buildd upp omkring 300 nya paket, ett tydligt tecken på att infrastrukturen fungerar väl.

    Vad händer härnäst

    Den pågående bootstrap-fasen, där hela Debians paketarkiv successivt byggs för den nya arkitekturen, beräknas ta ungefär en vecka. Tidsåtgången beror på om fler byggservrar kopplas in, vilket i så fall skulle öka byggtakten avsevärt.

    När arkivet nått tillräcklig täckning kommer loong64 att behandlas som vilken annan officiell Debian-arkitektur som helst. Det innebär deltagande i alla release-milstolpar, tillgång till officiell installerare samt långsiktigt säkerhets- och underhållsstöd under hela Debian 14:s livscykel.

    Varför detta är betydelsefullt

    Att loong64 nu får officiell status är viktigt både tekniskt och strategiskt. För Debian innebär det ökad arkitekturmångfald och en förstärkt roll som global och hårdvaruneutral Linux-distribution. För LoongArch-plattformen betyder det tillgång till tusentals färdigpaketerade program och ett stort internationellt utvecklar- och användarsamfund.

    Sammanfattning

    Befordran av loong64 från Debian Ports till officiellt stöd visar hur ett öppet projekt kan utveckla och integrera helt nya processorarkitekturer på produktionsnivå. Om allt går enligt plan blir Debian 14 Forky den första Debian-utgåvan där LoongArch får samma status som etablerade arkitekturer som x86, ARM och RISC-V.

    Faktaruta: LoongArch (loong64 i Debian)

    LoongArch är en RISC-instruktionsuppsättning (ISA) från Loongson. I Debian kallas 64-bitarsvarianten loong64 (motsvarar LA64) och är nu på väg in som officiellt stödd arkitektur i Debian 14.

    Fördelar

    • Fristående ISA (inte x86/ARM) som ger en alternativ CPU-plattform med egen utvecklingslinje.
    • Uppströms Linux-stöd (LoongArch kom in som ny arkitektur i Linux 5.19), vilket ger bättre långsiktighet än “out-of-tree”-patchar.
    • Stöd i verktygskedjan: GCC har LoongArch-stöd sedan 12.1, och Rust-plattformen för loongarch-linux anger Linux 5.19 som miniminivå.
    • Debian-stöd innebär automatiska byggbyggen (buildd), säkerhetsflöden och vanliga release-milstolpar.

    CPU:er som använder LoongArch (exempel)

    • Loongson 3A5000 (desktop/”general purpose”, LA464-kärnor).
    • Loongson 3C5000 (server, 16 LA464-kärnor).
    • Loongson 3A6000 (finns bl.a. som industrial-grade-variant, LA664-mikroarkitektur).
    • Nyare serverfamilj 3C6000/derivat har visats offentligt i medier (serverfokus, många kärnor).
    • Nyare “terminal/mobil/industri”-kretsar som 2K3000 och 3B6000M har nämnts av Loongson/press (inbyggt/edge/laptop-inriktning).

    Bra att känna till

    • LoongArch finns i flera varianter: LA32R, LA32S och LA64.
    • Program måste vara kompilerade för loong64/LA64 (binärkompatibilitet med x86/ARM finns inte).
    • Ekosystemet växer snabbt, men täckningen kan variera per distro och paket beroende på portningsstatus.

    Källor (urval): Debian-annonseringen om loong64 som officiell arkitektur, Linux-kärnans LoongArch-dokumentation (v5.19), GCC/nyhetsnotiser om LoongArch-stöd, samt Loongsons produktsidor för 3A5000/3C5000/3A6000 och press om 3C6000/2K3000/3B6000M.

  • Bcachefs flyttar ut ur Linuxkärnan – blir DKMS-modul

    Linux-filsystemet Bcachefs hamnar åter i rampljuset. Efter att ha plockats bort från den kommande Linuxkärnan 6.17 flyttar filsystemet nu ut från kärnan och över till DKMS-moduler. För användare innebär förändringen stabilitet även vid uppdateringar, men för distributionerna väntar ett omfattande arbete med paketering och integration.

    Bcachefs – dramat fortsätter i Linux-kärnans egen såpopera.

    Det kontroversiella Linux-filsystemet Bcachefs tar ett nytt kliv i sin utveckling. Efter en infekterad konflikt mellan projektets skapare Kent Overstreet och Linus Torvalds har stödet för filsystemet plockats bort från den kommande Linuxkärnan 6.17. Nu meddelar Overstreet att Bcachefs i stället kommer att distribueras via DKMS – ett system som automatiskt ser till att externa kärnmoduler fortsätter fungera vid uppdateringar.

    Från kärnan till DKMS

    För användare betyder detta att Bcachefs inte längre följer med kärnan direkt. I stället byggs modulen om automatiskt med varje ny kärnversion, på samma sätt som exempelvis NVIDIA-drivrutiner, VirtualBox och ZFS. Det gör att filsystemet fortsätter fungera smidigt, utan att användarna behöver kompilera om något själva.

    I praktiken kommer de flesta inte märka någon större skillnad – DKMS-moduler kan inkluderas i initramfs på samma sätt som kärnmoduler, vilket gör att systemet startar som vanligt även om rotfilsystemet ligger på Bcachefs.

    Nya krav på distributionerna

    För distributionerna blir övergången desto mer betydelsefull. Paketflöden måste anpassas och testas för att säkerställa att allt fungerar vid uppdateringar.

    • Fedora har redan ett paket för Bcachefs-verktygen och väntas ligga relativt bra till.
    • openSUSE, som snabbt tog bort stödet i sin kommande 6.17-kärna, behöver nu lägga extra arbete på att integrera DKMS.
    • Debian har haft ett mer komplicerat förhållande – verktygspaketet blev övergivet och raderades, men är på väg tillbaka i experimental-grenen.
    • Arch Linux och NixOS samarbetar nära med upstream och har bidragit till att förbättra DKMS-stödet.

    En särskild utmaning är bcachefs-tools, användarverktygen som hittills inte varit lika kritiska eftersom kärnan själv stått för reservfunktioner. Med övergången till DKMS måste distributionerna vara betydligt mer aktiva med underhåll och uppdateringar.

    Stabilitet före allt

    Trots turbulensen betonar Overstreet att stabilitet och kvalitetssäkring står i centrum. Version 6.16 beskrivs som en solid utgåva – inga nya kritiska buggar har dykt upp, och de senaste fixarna har mest handlat om prestanda och testmiljöer snarare än användarproblem.

    Han efterlyser samtidigt fler testare och paketerare som kan bidra till att finslipa den nya modellen. Utvecklingen har varit intensiv, men nu när de värsta buggarna är avklarade finns mer utrymme att fokusera på distributionerna.

    Vad betyder det för användarna?

    För vanliga användare är beskedet lugnande: de flesta kommer att fortsätta köra version 6.16 även när Linux 6.17 når ut, vilket ger distributionerna tid att anpassa sig. På längre sikt förväntas DKMS göra Bcachefs mer flexibelt och lättare att underhålla över olika kärnor.

    Ett filsystem med potential

    Bakom allt drama finns ett filsystem med stora ambitioner. Bcachefs kombinerar prestanda och funktioner från moderna copy-on-write-filsystem som Btrfs och ZFS, men med enkelheten och hastigheten hos klassiker som ext4 och XFS.

    Att det nu försvinner ur standardkärnan uppfattas därför av många som en förlust för Linux-ekosystemet. Men hoppet lever kvar om att Overstreet och Torvalds en dag kan hitta tillbaka till ett samarbete – och att Bcachefs då får en självklar plats i kärnan igen.

    https://linuxiac.com/bcachefs-transitioning-to-dkms-packaging

  • Linux fyller 34 år – från hobbyprojekt till världens motor

    Den 25 augusti 1991 skrev den unge finske studenten Linus Torvalds ett kort inlägg på diskussionsgruppen comp.os.minix (usernet). Han berättade att han höll på att bygga ett fritt operativsystem – ”bara som en hobby”. Ingen kunde då ana att detta lilla projekt skulle växa till ett av världens mest inflytelserika tekniska fenomen: Linux. I dag, 34 år senare, finns Linux överallt – från mobiltelefoner och superdatorer till satelliter och rymdstationer.

    Är det party, så är det party – det finns ingen morgondag.

    Den 25 augusti 1991 skrev den då 21-årige Linus Torvalds, student i Helsingfors, ett inlägg på en diskussionsgrupp där han berättade att han arbetade på ett nytt operativsystem. Han beskrev det som ett fritt system för 386/486-datorer – ”bara en hobby, inte stort och professionellt som GNU”.

    Det som började som ett litet experiment har sedan dess vuxit till att bli ett av världens viktigaste tekniska fundament. I dag, 34 år senare, driver Linux allt från mobiltelefoner, smarta prylar och TV-apparater till superdatorer, aktiebörser och den internationella rymdstationen.

    Hello everybody out there using minix –
    I’m doing a (free) operating system (just a hobby, won’t be big and professional like gnu) for 386(486) AT clones. This has been brewing since april, and is starting to get ready. I’d like any feedback on things people like/dislike in minix, as my OS resembles it somewhat (same physical layout of the file-system (due to practical reasons) among other things).

    I’ve currently ported bash(1.08) and gcc(1.40), and things seem to work. This implies that I’ll get something practical within a few months, and I’d like to know what features most people would want. Any suggestions are welcome, but I won’t promise I’ll implement them 🙂

    Linus

    PS. Yes – it’s free of any minix code, and it has a multi-threaded fs. It is NOT portable (uses 386 task switching etc), and it probably never will support anything other than AT-harddisks, as that’s all I have :-(.

    Klicka här för svensk översättning
    Hej alla där ute som använder Minix –
    Jag håller på att göra ett (fritt) operativsystem (bara en hobby, kommer inte att bli stort och professionellt som GNU) för 386(486) AT-kloner. Det har varit under utveckling sedan april, och börjar bli redo. Jag skulle gärna vilja ha feedback på vad folk gillar/inte gillar i Minix, eftersom mitt OS liknar det något (samma fysiska layout på filsystemet (av praktiska skäl) bland annat).
    
    Jag har för närvarande portat bash(1.08) och gcc(1.40), och saker verkar fungera. Detta innebär att jag kommer att få något praktiskt inom ett par månader, och jag skulle vilja veta vilka funktioner de flesta vill ha. Alla förslag är välkomna, men jag lovar inte att jag kommer att implementera dem 🙂
    
    Linus
    
    PS. Ja – det är helt fritt från Minix-kod, och det har ett flertrådat filsystem. Det är INTE portabelt (använder 386-task switching osv.), och det kommer förmodligen aldrig att stödja något annat än AT-hårddiskar, eftersom det är allt jag har :-(.
      

    Från hobby till globalt fenomen

    Torvalds kunde knappast ana att hans lilla sidoprojekt skulle förändra världen. Linux har blivit navet i den digitala infrastrukturen. Android-telefoner, servrar på nätet, routers i hemmet, börshandel, bilsystem och till och med rymdfarkoster – alla använder Linux på ett eller annat sätt.

    Superdatorlistan toppas helt av Linuxmaskiner, och systemet är en självklar del i forskning, teknik och vardag.

    ▌ Fakta: Linux-kärnan

    • Första versionen: 1991 (Linus Torvalds)
    • Språk: C med inslag av assembler
    • Licens: GPLv2 (fri och öppen källkod)
    • Utveckling: globalt samarbete med tusentals bidragsgivare
    • Utgivningstakt: nya stabila versioner ungefär var 2–3:e månad

    Betydelse i det moderna samhället

    • Internet: Stommen i majoriteten av världens webbservrar.
    • Superdatorer: Dominerar de snabbaste beräkningsklustren.
    • Mobil: Android bygger på Linux-kärnan.
    • Inbyggda system: Routrar, TV-apparater, bilar, medicinsk utrustning m.m.
    • Moln & finans: Vanligt i banker, börser och datacenter/plattformar.
    • Rymden: Används i satelliter och rymdstationer.

    Kort sagt: Linux-kärnan är hjärtat i den digitala infrastrukturen – från fickan till rymden.

Etikett: Linux-kärnan

  • DirtyClone: ny Linux-sårbarhet kan ge angripare root-behörighet

    Linuxvärlden har drabbats av ännu en allvarlig kärnsårbarhet. Den nya bristen, kallad DirtyClone, är nära besläktad med DirtyFrag och kan i vissa fall låta en lokal angripare få root-behörighet på sårbara system. Även om felet inte kan utnyttjas direkt på distans är risken betydande, särskilt på system med containrar eller unprivileged user namespaces aktiverade. När…

  • OpenZFS 2.4.3: säkrare lagring och stöd för nyare Linux-kärnor

    OpenZFS 2.4.3 är här med bättre stöd för moderna Linux-kärnor, flera viktiga lagringsfixar och skärpt kontroll av komprimerad data. Uppdateringen riktar sig främst till servrar, NAS-system och andra miljöer där ZFS används för säker och pålitlig lagring. OpenZFS 2.4.3 har släppts som en ny underhållsversion av det öppna filsystemet och volymhanteraren ZFS. För den vanliga…

  • 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…

  • IPFire stärker skyddet mot nya Linux-sårbarheter

    IPFire 2.29 Core Update 202 är en viktig säkerhetsuppdatering för den Linux-baserade brandväggsdistributionen IPFire. Den nya versionen åtgärdar flera aktuella sårbarheter i Linux-kärnan, uppdaterar OpenVPN med stöd för snabbare VPN-trafik och innehåller ett stort antal förbättringar i brandvägg, intrångsskydd, DNS och IPsec. För den som använder IPFire som router, brandvägg eller VPN-gateway är detta en…

  • Dirty Frag: ny Linux-sårbarhet kan ge lokal användare root-behörighet

    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…

  • 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…

  • Linux får ett rejält lyft för NTFS – nu med riktigt skrivstöd

    Linux får nu ett kraftigt förbättrat stöd för filsystemet NTFS, som länge varit standard i Windows. Med den nya NTFS-drivrutinen i Linux-kärnan 7.1 blir det möjligt att inte bara läsa utan också skriva fullt ut till NTFS-diskar, samtidigt som prestanda, stabilitet och underhåll förbättras. Linux får ett rejält lyft för NTFS – nu med riktigt…

  • Linux 7.1 avvecklar stöd för 486-, 486SX- och AMD Elan-processorer

    I utvecklingsgrenen för Linux 7.1 har x86-koden uppdaterats så att stöd för processorfamiljerna M486, M486SX och AMD Elan tas bort. Ändringen innebär att kärnans lägsta praktiska målplattform för 32-bitars x86 höjs från 486-klass till 586-klass. För dagens användare får detta i stort sett inga praktiska konsekvenser, men tekniskt markerar beslutet ett tydligt steg i den…

  • Fedora 44 försenas – varför några få buggar kan stoppa ett helt operativsystem

    Fedora 44 har försenats efter att flera allvarliga fel upptäckts i systemets mest kritiska delar, som installation, grafik och krypterad uppstart. I stället för att hålla det planerade releasedatumet väljer utvecklarna att pausa lanseringen – ett beslut som visar hur avgörande kvalitetssäkring är när modern programvara ska fungera på många olika typer av hårdvara. Det…

  • Linux From Scratch 13.0 släppt – bygg ditt eget Linux från grunden

    Linux From Scratch har släppt version 13.0 av sin välkända guide för att bygga ett komplett Linux-system från källkod. Den nya utgåvan innebär flera viktiga förändringar, bland annat att projektet nu helt överger SysVinit och enbart erbjuder en systemd-baserad version, samtidigt som ett stort antal centrala komponenter har uppdaterats. Linuxvärlden domineras i dag av färdiga…

  • GNU Hurd tar steget in i 64-bitarsvärlden

    GNU Hurd har tagit ett historiskt steg in i 64-bitarsvärlden. Efter över tre decennier som ett experimentellt 32-bitarsprojekt kan den alternativa GNU-kärnan nu köras nativt på modern x86_64-hårdvara – tack vare integrationen i GNU Guix. Det innebär inte att Hurd ersätter Linux, men det gör projektet tekniskt relevant igen och öppnar dörren för en ny…

  • Kan artificiell intelligens få en plats i Linux-kärnan?

    Kan Linux-kärnan bli smartare med hjälp av artificiell intelligens?En ny diskussion bland Linux-utvecklare väcker frågan om maskininlärning kan användas för att optimera hur operativsystemets innersta delar fungerar. Förslaget är försiktigt, kontroversiellt – och helt utanför kärnan själv. Tänk dig att Linux-kärnan – själva hjärtat i operativsystemet – kunde lära sig av sitt eget beteende och…

  • Debian 13.3 är här – stabilitet före allt annat

    Debian fortsätter att finslipa sin senaste stabila version. Med Debian 13.3 samlas månader av säkerhetsuppdateringar och buggfixar i en ny punktrelease som gör systemet tryggare, stabilare och enklare att installera på ny hårdvara – utan att ändra det som redan fungerar. Två månader efter föregående uppdatering har Debian Project släppt Debian 13.3, den tredje punktuppdateringen…

  • Debian gör loong64 till officiellt stödd arkitektur i Debian 14

    När Debian officiellt gör loong64 till en fullt stödd arkitektur tas ett historiskt steg för både projektet och den kinesiska processorplattformen LoongArch. Efter mer än två års arbete i Debian Ports är loong64 nu på väg in i huvudutgåvan Debian 14 Forky, där den kommer att omfattas av samma byggsystem, säkerhetsuppdateringar och långsiktiga stöd som…

  • Bcachefs flyttar ut ur Linuxkärnan – blir DKMS-modul

    Linux-filsystemet Bcachefs hamnar åter i rampljuset. Efter att ha plockats bort från den kommande Linuxkärnan 6.17 flyttar filsystemet nu ut från kärnan och över till DKMS-moduler. För användare innebär förändringen stabilitet även vid uppdateringar, men för distributionerna väntar ett omfattande arbete med paketering och integration. Det kontroversiella Linux-filsystemet Bcachefs tar ett nytt kliv i sin…

  • Linux fyller 34 år – från hobbyprojekt till världens motor

    Den 25 augusti 1991 skrev den unge finske studenten Linus Torvalds ett kort inlägg på diskussionsgruppen comp.os.minix (usernet). Han berättade att han höll på att bygga ett fritt operativsystem – ”bara som en hobby”. Ingen kunde då ana att detta lilla projekt skulle växa till ett av världens mest inflytelserika tekniska fenomen: Linux. I dag,…