A Linux kernel hiba, amelyet CVE-2026-46331 azonosítóval és „pedit COW” néven jegyeznek, újabb példája annak, hogyan lehet a lapcache (page cache) sérülékenységeit kihasználva lokális, nem privilegizált felhasználóból root jogosultságot szerezni. A sebezhetőség a kernel forgalomszabályozó (traffic-control) alrendszerében, pontosabban az act_pedit (packet editing) akcióban található, és egy out-of-bounds write-on keresztül vezet a lapcache memóriában tárolt fájlok korrupciójához.

A sérülékenység súlyosságát jól mutatja, hogy a CVE kiosztását követően egy napon belül nyilvános, működő exploit jelent meg, miközben a Red Hat „important” besorolást adott a hibának. A támadás különösen alattomos, mert nem módosítja a fájlt a lemezen: a támadó a memóriában lévő, cache-elt példányt mérgezi meg, így a klasszikus integritás-ellenőrzések (pl. fájl-hash ellenőrzés) tisztának mutatják a rendszert, miközben a támadó már root shellt futtat.

Hogyan működik a pedit COW hiba?

A Linux tc (traffic control) eszköze lehetővé teszi a hálózati csomagok fejléceinek módosítását a kernelben. Ehhez használható az act_pedit akció, amelyet a kernelben a tcf_pedit_act() függvény valósít meg. A tervezett működés szerint a kernel a módosítás előtt másolatot készít az érintett adatról – ez a klasszikus copy-on-write (COW) minta: először privát másolat, majd azon történik az írás.

A probléma ott jelentkezik, hogy a függvény túl korán ellenőrzi az írható tartományt. Bizonyos „edit key”-ek (azaz a pedit által használt módosítási leírók) csak futásidőben határozzák meg a tényleges offsetet, amelyre írni kell. A kód azonban még azelőtt validálja a tartományt, hogy a végleges offset ismert lenne. Így előállhat az a helyzet, hogy:

• a kernel úgy gondolja, hogy a módosítás a privát másolaton történik,
• valójában viszont a privát régión kívülre esik az írás,
• és így egy megosztott lapcache-oldal (page-cache page) módosul.

Ha ez a megosztott lap egy cache-elt fájlhoz tartozik – például egy setuid root binárishoz, mint a /bin/su –, akkor a fájl memóriában lévő képe sérül. A lemezen lévő fájl változatlan marad, de a futtatáskor a kernel a már mérgezett, memóriában lévő példányt használja.

Az exploit ezt használja ki: a támadó kiválaszt egy setuid root binárist (a PoC esetében /bin/su), eléri, hogy annak lapjai a page cache-ben legyenek, majd az act_pedit hibáján keresztül beleír egy kis payloadot a cache-elt példányba. Ezután egyszerűen futtatja a binárist, amely így már a módosított, root joggal futó kódot hajtja végre. A lemezen tárolt fájl hash-e eközben változatlan, így egy offline integritás-ellenőrzés nem jelez problémát.

Ismerős minta: Dirty Pipe, Copy Fail, DirtyClone, Dirty Frag

A pedit COW nem elszigetelt jelenség, hanem egy visszatérő hibaminta újabb megnyilvánulása. A cikkben is említett Dirty Pipe, Copy Fail, DirtyClone és Dirty Frag mind ugyanarra a logikai mintára épülnek:

• a kernel egy gyors útvonalon (fast path) ír egy lapra,
• anélkül, hogy biztosítaná: az a lap teljesen privát tulajdonban van,
• és így a page cache-ben lévő megosztott adat sérül.

Ami a pedit COW esetében újdonság, az az elérési pont. Itt nem egy speciális fájlrendszer-műveleten vagy pipe-kezelésen keresztül érhető el a bug, hanem a hálózati forgalomszabályozó alrendszeren át, egy olyan komponenssel, amelyet sok rendszeren alapértelmezetten elérhetővé tesznek.

Miért kritikus a user namespace + CAP_NET_ADMIN kombináció?

Az exploit két feltételt igényel:

• act_pedit modulnak elérhetőnek kell lennie (betölthető kernelmodul vagy beépített funkció),
• nem privilegizált user namespace-eknek engedélyezve kell lenniük, hogy a támadó namespace-en belül CAP_NET_ADMIN képességet szerezzen.

A Linux user namespace-ek lényege, hogy egy folyamat saját névteret hozhat létre, amelyben a kernel külön „nézi” a felhasználó- és csoportazonosítókat. Egy nem privilegizált felhasználó így létrehozhat egy olyan namespace-t, ahol lokálisan rootnak látszik, és a kernel bizonyos képességeket (capabilities) – például CAP_NET_ADMIN – megad neki csak abban a namespace-ben.

Ez a modell teszi lehetővé a root nélküli konténereket és egyes sandboxolt környezeteket, de egyben azt is jelenti, hogy a támadó tc szabályokat tud konfigurálni a saját névterében, és így eléri az act_pedit akciót. Innen már „csak” a kernel hibáját kell kihasználni a page cache mérgezéséhez.

A PoC szerzője szerint a tesztelt RHEL és Debian rendszereken mindkét feltétel teljesült: az act_pedit elérhető volt, és a nem privilegizált user namespace-ek alapértelmezetten engedélyezve voltak, így a támadás nem privilegizált felhasználóból root jogosultságig vezetett.

Érintett disztribúciók és állapotuk

A beszámolók alapján a helyzet a nagyobb disztribúcióknál a következőképpen néz ki:

• Debian:
  • A PoC szerzője Debian 13 (trixie) rendszeren demonstrálta a nem privilegizáltból rootig vezető exploitot, ahol a user namespace-ek alapértelmezetten nyitva vannak.
  • Trixie már kapott javítást a Debian security csatornán keresztül.
  • Debian 11 és Debian 12 továbbra is sérülékenynek van listázva.
• Ubuntu:
  • Ubuntu 24.04 esetén az exploit működéséhez az AppArmor profilokon keresztül kellett olyan útvonalat találni, amely még engedi a user namespace-ek használatát.
  • Ubuntu 26.04 esetén az alapértelmezett AppArmor profilok már blokkolják a nem privilegizált user namespace-eket, így az exploit lánc alapértelmezésben megszakad – ugyanakkor a kernel maga továbbra is sérülékeny, ha valaki ezeket a korlátozásokat feloldja.
  • Az Ubuntu biztonsági közleménye szerint a támogatott kiadások 18.04-től 26.04-ig érintettek, a közlemény időpontjában (június 25.) még sérülékeny állapotban.
• Red Hat / RHEL:
  • A Red Hat szerint RHEL 8, RHEL 9 és RHEL 10 érintett.
  • RHEL 7 nem szerepel az érintett verziók között a Red Hat közleményében.

Fontos kiemelni, hogy a disztribúciók különböző konfigurációs döntései – például a user namespace-ek alapértelmezett engedélyezése vagy tiltása, AppArmor/SELinux profilok szigorúsága – jelentősen befolyásolják, hogy a hiba gyakorlatban mennyire könnyen kihasználható. A kernel szintjén azonban a sebezhetőség ugyanaz.

Mit tegyünk: javítás, mitigáció, priorizálás

A legfontosabb lépés: telepítsük a javított kernelt és indítsuk újra a rendszert. A kernelhibák esetén nincs valódi alternatívája a frissítésnek, ha hosszú távon biztonságos rendszert akarunk.

Különösen sürgősen érdemes frissíteni azokat a gépeket, ahol a „lokális felhasználó” nem jelent megbízható adminisztrátort, például:

• multi-tenant szerverek, hosting környezetek,
• CI/CD futtatók (runnerek),
• Kubernetes node-ok,
• build farmok,
• megosztott kutatási vagy labor gépek.

Ha valamilyen okból azonnal nem tudunk frissíteni, két fő mitigációs útvonal áll rendelkezésre, amelyek megtörik az exploit láncot:

1. act_pedit modul letiltása

Ha a rendszeren nincs szükség tc pedit szabályokra, érdemes ellenőrizni, hogy az act_pedit modul használatban van-e:

lsmod | grep act_pedit

Ha nincs rá szükség, egy egyszerű modprobe szabállyal megakadályozható a modul betöltése:

echo 'install act_pedit /bin/true' | sudo tee /etc/modprobe.d/disable-act_pedit.conf

Ez a trükk azt eredményezi, hogy ha a rendszer bármikor be akarná tölteni az act_pedit modult, a kernel helyett a /bin/true fut le, így a modul ténylegesen nem kerül betöltésre. Ez a módszer régóta bevett gyakorlat bizonyos, ritkán használt, de potenciálisan veszélyes modulok letiltására.

2. Nem privilegizált user namespace-ek tiltása

A másik hatékony lépés a nem privilegizált user namespace-ek letiltása, amivel elvágjuk a támadó útját a namespace-lokális CAP_NET_ADMIN megszerzéséhez. A disztribúciók ezt különböző sysctl paraméterekkel szabályozzák:

• RHEL esetén:
  • user.max_user_namespaces=0
• Debian/Ubuntu esetén:
  • kernel.unprivileged_userns_clone=0

Ezek a beállítások jelentős funkcionalitást törhetnek el:

• root nélküli konténerek,
• egyes CI sandboxok,
• bizonyos sandboxolt böngészők és desktop alkalmazások.

Ezért ilyen változtatást mindig tesztkörnyezetben érdemes kipróbálni, mielőtt széles körben bevezetjük, különösen nagyobb szervezeteknél vagy kritikus szolgáltatásoknál.

Miért nem elég az integritás-ellenőrzés és a cache ürítése?

Mivel az exploit csak a memóriában lévő, cache-elt példányt módosítja, a lemezen lévő fájl érintetlen marad. Ez több fontos következménnyel jár:

• Fájl-integritás ellenőrzés (pl. hash-ek, AIDE, tripwire) nem jelez eltérést, hiszen a lemezre írt tartalom nem változik.
• A támadó által megnyitott root shell független a cache állapotától: ha a payload már lefutott és a shell megnyílt, a továbbiakban a cache állapota nem befolyásolja a meglévő jogosultságot.

Elméletben a page cache ürítése (például:

echo 3 | sudo tee /proc/sys/vm/drop_caches

) visszaállítja a memóriában lévő példányt a lemezről, így a mérgezett cache-elt oldal eltűnik. Ez azonban nem szünteti meg a már megszerzett root hozzáférést. Ha egyszer az exploit lefutott, a rendszert kompromittáltnak kell tekinteni, és ennek megfelelően kell eljárni (naplóelemzés, incidenskezelés, szükség esetén újratelepítés, kulcsok/credentialek cseréje).

Fejlesztői nézőpont: hogyan született a javítás?

Érdekes – és a kernelbiztonság szempontjából tanulságos – részlet, hogy a hiba javítása már hetekkel a CVE kiosztása előtt megjelent a netdev levelezőlistán, „rutin adat-korrupciós javításként” keretezve. A patch nyilvános volt, de nem kísérte biztonsági figyelmeztetés vagy CVE hivatkozás.

A CVE-t csak akkor osztották ki, amikor a javítás merge-ölésre került (június 16-án), és egy napon belül megjelent a weaponizált proof-of-concept exploit. Ez a folyamat rávilágít arra, hogy a page cache korrupciós hibák esetén a „majd jön a scanner szabály” megközelítés túl lassú. A támadók számára elég a patch-et elemezni, és gyorsan exploitot írni, miközben a védelmi oldalon még csak most kezdik értelmezni a hibát.

Kernel-fejlesztői szempontból ez megerősíti, hogy minden olyan kód, amely:

• megosztott lapokon dolgozik,
• copy-on-write logikát használ,
• és gyors útvonalon (fast path) fut,

különösen nagy figyelmet igényel. A határ-ellenőrzések időzítése (mikor validáljuk az offsetet, mikor készül a másolat) kritikus, és a futásidőben feloldódó offsetek, indirekt mutatók, illetve bonyolult kulcs-struktúrák könnyen vezetnek hasonló hibákhoz.

Tanulságok Linux rendszergazdáknak és fejlesztőknek

Rendszergazdai oldalról a pedit COW története több fontos üzenetet hordoz:

• Ne becsüljük alá a „lokális” sebezhetőségeket: multi-tenant, CI, konténeres környezetben a „lokális felhasználó” gyakran ismeretlen, potenciálisan rosszindulatú kódot futtat.
• Ismerjük a kernel moduljainkat: ha egy funkcióra (pl. act_pedit) nincs szükség, érdemes megfontolni a modul letiltását.
• Gondoljuk át a user namespace policy-t: a root nélküli konténerek kényelme és a biztonsági kockázat között tudatos döntést kell hozni, különösen megosztott rendszereken.
• Ne támaszkodjunk kizárólag integritás-ellenőrzésre: a memóriában történő támadások ellen a fájl-hash-ek önmagukban nem védenek.

Fejlesztői oldalról pedig a fő tanulság, hogy a page cache és COW logika körüli hibák szinte automatikusan potenciális privilege escalation sebezhetőségek. Az ilyen kódot:

• szigorúbb review-n,
• formálisabb tesztelésen,
• és célzott fuzzingon

érdemes átfuttatni, különösen akkor, ha nem privilegizált felhasználók által elérhető útvonalakon fut.

Összességében a pedit COW exploit újabb emlékeztető arra, hogy a Linux kernel komplex, nagy teljesítményű alrendszerei – mint a hálózati forgalomszabályozás – és a modern izolációs mechanizmusok (user namespace-ek, konténerek) kombinációja olyan támadási felületet hoz létre, amelyet folyamatosan, proaktívan kell védeni. A gyorsan megjelenő, nyilvános exploitok korában a gyors patch-elés és a tudatos hardening már nem opcionális, hanem alapvető üzemeltetési követelmény.