A CVE-2026-31431 egy súlyos Linux kernel sérülékenység, amely lehetővé teheti, hogy egy helyi hozzáféréssel rendelkező támadó teljes rendszergazdai (root) jogosultságot szerezzen. A hiba különösen veszélyes, mert a támadás a rendszer memóriájában történik, így sok hagyományos biztonsági ellenőrzés nem veszi észre a módosításokat.

Gyakorlatilag minden modern Linux disztribúció érintett lehet, beleértve a szervereket, felhős és konténeres környezeteket is, ezért a biztonsági frissítések telepítése kiemelten fontos. Bár léteznek ideiglenes védekezési lehetőségek, a teljes megoldást csak a javított kernelverzióra történő frissítés jelenti.

2026 tavaszán került nyilvánosságra a CVE-2026-31431 azonosítójú Linux kernel sérülékenység, amely gyorsan komoly figyelmet kapott mind a kutatók, mind az üzemeltetők részéről. Bár első ránézésre „csak” egy helyi jogosultságkiterjesztési hibáról van szó, a gyakorlati hatása ennél jóval súlyosabb: egy viszonylag egyszerűen kihasználható mechanizmuson keresztül gyakorlatilag bármely érintett rendszeren root jogosultság szerezhető.

A hiba a Linux kernel kriptográfiai alrendszerében található, azon belül is az AF_ALG userspace API-hoz tartozó algif_aead komponensben. Ez az interfész lehetővé teszi, hogy felhasználói térből közvetlenül a kernel kriptográfiai implementációit használjuk, ami teljesítmény és rugalmasság szempontjából előnyös, ugyanakkor a komplexitása miatt hibalehetőségeket is rejt. A konkrét sérülékenység gyökere egy évekkel ezelőtti optimalizációs döntésre vezethető vissza: a fejlesztők úgy módosították az AEAD műveletek működését, hogy azok „in-place” módon történjenek, vagyis ugyanazt a memóriaterületet használják bemenetként és kimenetként is. Ez a változtatás ugyan javította a teljesítményt, de egy finom, sokáig rejtve maradó memória-kezelési hibát vezetett be.

A probléma lényege, hogy bizonyos körülmények között a kernel hibásan kezeli a memóriapage-ek láncolását, amikor az AF_ALG socketeket és a splice() rendszerhívást kombinálják. Egy támadó ezt kihasználva elérheti, hogy kontrollált módon adatot írjon olyan memóriaoldalakra, amelyek valójában fájlok page cache-éhez tartoznak. Ez különösen veszélyes, mert nem a fájlrendszeren történik a módosítás, hanem kizárólag memóriában, így a hagyományos integritás-ellenőrzési mechanizmusok ezt nem feltétlenül veszik észre.

A kihasználás tipikus forgatókönyve az, hogy a támadó egy setuid root bináris – például egy hitelesítési vagy jogosultságkezelési eszköz – memóriában cache-elt példányát módosítja apró lépésekben. Bár egyszerre csak néhány bájt írható felül, ez elegendő lehet a program viselkedésének megváltoztatásához. Amikor a módosított bináris lefut, már a támadó által befolyásolt kód hajtódik végre, ami végül root shellhez vezet. Mivel a fájl a lemezen változatlan marad, a támadás nehezen észlelhető, és utólagos forenzikus vizsgálat során is kevés nyomot hagy.

A sérülékenység egyik legaggasztóbb tulajdonsága, hogy rendkívül széles körben érinti a rendszereket. A hibás kód már 2017 óta része a kernelnek, így gyakorlatilag minden modern Linux disztribúció érintett, beleértve a szervereken, felhő infrastruktúrákban és konténeres környezetekben használt változatokat is. Ez azt jelenti, hogy nemcsak klasszikus multi-user rendszereken jelent veszélyt, hanem például Kubernetes klaszterekben vagy shared hosting környezetekben is, ahol egyetlen kompromittált konténerből kiindulva a teljes host rendszer átvehető.

További súlyosbító tényező, hogy az exploit megírása nem különösebben bonyolult. A publikált példák alapján néhány száz soros, sőt akár ennél rövidebb kód is elegendő a kihasználáshoz, és nincs szükség bonyolult időzítési támadásokra vagy kernelverzió-specifikus finomhangolásra. A működés determinisztikus, így a sikerességi arány közel áll a száz százalékhoz. Ez jelentősen csökkenti a támadók belépési küszöbét, és hozzájárult ahhoz is, hogy a sérülékenység rövid időn belül megjelent valós támadásokban.

A javítás kernel szinten viszonylag gyorsan elkészült 2026 áprilisának elején, azonban a különböző disztribúciók eltérő ütemben vették át és backportolták a patch-et. A rolling release rendszerek és a gyors frissítési ciklussal rendelkező disztribúciók hamar kiadták a javított kernelverziókat, míg az enterprise környezetben használt, hosszú támogatási ciklusú rendszereknél a frissítések megjelenése lassabb volt. Ez egy klasszikus „patch gap” helyzetet eredményezett, ahol a sérülékenység részletei és az exploit már nyilvánosak voltak, de sok éles rendszer még nem kapta meg a javítást.

Érintett rendszerek és verziók

A sérülékenység minden olyan Linux kernelt érint, amelyben az érintett optimalizáció jelen van.

Érintett:

• Linux kernel 4.14-től egészen a 2026 eleji kiadásokig

• Gyakorlatilag minden nagy disztribúció:

  • Ubuntu (LTS és nem LTS verziók)

  • Debian

  • Red Hat Enterprise Linux (RHEL)

  • Rocky / AlmaLinux

  • SUSE / SLES

  • Amazon Linux

  • Arch Linux

  • konténer hostok (Docker, Kubernetes node-ok)

  • WSL2 környezetek

Nem érintett / javított (upstream kernel):

• 6.18.22+

• 6.19.12+

• 7.0 és újabb

Fontos, hogy enterprise disztribúciók esetén nem a kernel verziószám, hanem a backport számít, ezért egy régebbi verziószámú kernel is lehet már javított.

Disztribúció-specifikus patch státusz

A pontos verziók disztrónként eltérnek, de a minta jól kirajzolódik:

• Ubuntu

  • 2026 április elején érkeztek a patchek

  • minden támogatott release-hez backportolták

• Debian

  • stable és oldstable ágakhoz biztonsági frissítésként jött

• RHEL / Alma / Rocky

  • RHSA advisory keretében, backporttal

  • késleltetve, de széles körben elérhető

• SUSE

  • SLES és openSUSE ágakhoz külön advisory

• Arch / Fedora

  • nagyon gyorsan, friss kernel release-ben javítva

Mitigáció és védekezés

A probléma jellegéből adódóan a teljes védelem csak kernel frissítéssel érhető el, de bizonyos ideiglenes lépések csökkenthetik a kockázatot.

Elsődleges megoldás a kernel frissítés

• telepítsd a vendor által kiadott security update-et

• indítsd újra a rendszert

• ellenőrizd, hogy valóban az új kernel fut

Ez nem opcionális, mert a sérülékenység megbízhatóan kihasználható.

2. Ideiglenes mitigációk

Amennyiben az azonnali patch nem megoldható:

AF_ALG letiltása vagy korlátozása

• modul eltávolítása vagy blacklistelése

• access control policy alkalmazása

seccomp szűrés

• AF_ALG socket használat tiltása

• splice() syscall korlátozása nem megbízható processzeknél

SELinux / AppArmor

• policy szigorítása

• kernel crypto API hozzáférés limitálása

3. Kitettség csökkentése

• minimalizálni a helyi felhasználói hozzáférést

• konténerek izolációjának erősítése

• nem megbízható workloadok külön hoston futtatása

4. Detekciós lehetőségek

Bár a támadás nehezen észlelhető, bizonyos jelek figyelhetők:

• szokatlan AF_ALG socket aktivitás

• splice() hívások rendellenes mintázata

• setuid binárisok váratlan viselkedése

Ezek inkább indikátorok, mint megbízható detekciós módszerek.

Miért különösen kritikus?

Ez a sérülékenység nem technikai bonyolultsága miatt veszélyes, hanem azért, mert több kedvezőtlen tulajdonság egyszerre van jelen. Egyrészt széles körben elterjedt kódban található, másrészt a kihasználása egyszerű és stabil, harmadrészt a hatása teljes jogosultság megszerzése. Ehhez társul az is, hogy a támadás memóriában történik, így a klasszikus fájlintegritás-ellenőrzés vagy logelemzés sok esetben nem elegendő a felismeréséhez.