A Bad Epoll néven ismert, CVE-2026-46242 azonosítójú Linux kernel sebezhetőség egy tipikus, mégis különösen veszélyes kategóriába tartozik: egy use-after-free típusú memória-hibáról van szó, amelyet egy nem privilegizált, helyi felhasználó is kihasználhat, és így root jogosultságot szerezhet. A hiba érinti a modern Linux desktop és szerver rendszereket, valamint az Androidot is, és már elérhető hozzá javítás az upstream kernelben.

A sebezhetőség érdekessége, hogy ugyanabban a szűk kódrészletben található, ahol Anthropic legerősebb AI modellje, a Mythos korábban már felfedezett egy másik hibát. Az AI az első problémát kiszúrta (ez lett a CVE-2026-43074), de a Bad Epoll-t nem. Ezt végül egy kutató, Jaeyoung Chung azonosította, és működő exploitot is készített hozzá.

Mi az az epoll, és miért kritikus a modern Linux rendszerekben?

Az epoll a Linux kernel egyik alapvető event notification mechanizmusa, amelyet nagy terhelésű, sok párhuzamos kapcsolatot kezelő alkalmazások használnak. Célja, hogy egy program hatékonyan tudjon figyelni nagyszámú fájlleírót (file descriptor) – tipikusan hálózati socketeket, pipe-okat, fájlokat – anélkül, hogy folyamatosan aktívan „pörgetné” a CPU-t.

Technikailag az epoll egy kernelbeli infrastruktúra, amelyet a következő rendszerhívásokon keresztül érünk el:

• epoll_create / epoll_create1 – epoll instance létrehozása (egy speciális fájlleíró, amely az eseményhalmazt reprezentálja)
• epoll_ctl – fájlleírók hozzáadása, módosítása, törlése az epoll halmazból (EPOLL_CTL_ADD, EPOLL_CTL_MOD, EPOLL_CTL_DEL)
• epoll_wait – blokkoló vagy időzített várakozás eseményekre

Az epoll a korábbi select() és poll() API-k skálázhatóbb alternatívája. Míg a select/poll esetén a felhasználói tér minden hívásnál egy teljes bitmaszkot vagy tömböt másol a kernelbe, addig az epoll egy perzisztens kernelstruktúrát tart fenn, amelyben a figyelt fájlleírók listája csak változáskor módosul. Ez jelentősen csökkenti a rendszerhívások és a memória-másolások számát nagy FD-szám mellett.

Webszerverek (nginx, Apache event MPM), reverse proxyk, adatbázisok, proxy szerverek, konténer runtime-ok, sőt böngészők (például a Chrome) is erősen támaszkodnak rá. Mivel a modern Linux felhasználói tér jelentős része erre épít, epoll-t nem lehet egyszerűen letiltani anélkül, hogy a rendszer jelentős része használhatatlanná válna. Ez az oka annak, hogy a Bad Epoll esetében nincs érdemi workaround: a megoldás a kernel frissítése.

Use-after-free és versenyhelyzet: mi történik a kernelben?

A Bad Epoll egy klasszikus use-after-free hiba: két különböző kernelkód-útvonal ugyanazt a belső objektumot próbálja felszabadítani és kezelni. Az egyik ág már felszabadítja a memóriát, miközben a másik még ír bele. Ez a rövid, de kritikus időablak lehetőséget ad arra, hogy a támadó kernel memóriát korrumpáljon, majd ezt kihasználva privilégiumot emeljen.

A probléma gyökere egy 2023-as változtatás az epoll kódbázisában. Ebből a módosításból két külön sebezhetőség nőtt ki:

• CVE-2026-43074 – az elsőként felfedezett hiba, amelyet a Mythos AI azonosított, és amelyre 2026 elején érkezett javítás
• CVE-2026-46242 (Bad Epoll) – a „testvér” hiba, amelyet már emberi kutató talált meg

A Bad Epoll különlegessége, hogy a versenyablak rendkívül szűk: a két kódútvonal ütközése mindössze körülbelül hat gépi utasításnyi időtartományban következhet be. Egy naiv, véletlenszerű próbálkozás szinte soha nem találná el ezt az ablakot, ezért a kihasználás nem triviális.

Chung exploitja ezt a problémát úgy kezeli, hogy mesterségesen szélesíti az időablakot, és úgy szervezi a hívásokat (párhuzamos szálak, intenzív epoll műveletek, kontrollált memórianyomás), hogy a versenyhelyzet nagy valószínűséggel bekövetkezzen, miközben a rendszer nem omlik össze. Beszámolója szerint a támadás a tesztelt rendszereken kb. 99%-os sikerességi rátával érte el a root jogosultságot, ami egy versenyfeltételes exploitnál kifejezetten magas.

Miért különösen veszélyes? Chrome sandbox és Android

Két tényező emeli a Bad Epoll-t a „szokásos” kernel sebezhetőségek fölé:

• Chrome renderer sandboxból is triggerelhető – Chung beszámolója szerint a hiba kihasználható a Chrome renderelő folyamatának sandboxolt környezetéből. Ez azért jelentős, mert a Chrome sandbox célja éppen az, hogy a böngészőben futó, potenciálisan rosszindulatú kódot elszigetelje a kernel támadásától. Sok kernel bug egyszerűen nem érhető el ebből a környezetből, a Bad Epoll viszont igen, így egy böngészőn keresztüli exploit-láncban kulcselem lehet.
• Androidot is érinti – számos Linux kernel privilégium-eszkalációs hiba a gyakorlatban nem használható Androidon, mert a mobil kernel verziók, konfigurációk vagy a vendor patch-ek eltérnek. A Bad Epoll viszont elvben Androidon is kihasználható, és Chung dolgozik is egy Android-specifikus exploiton. Fontos részlet, hogy a hiba csak a 6.4-es és újabb kernelt érinti, így a 6.1-es kernelre épülő Android eszközök – például a Pixel 8 – nem sebezhetők ezzel a konkrét hibával.

A sebezhetőséget Chung zero-dayként küldte be a Google kernelCTF programjába, ahol a kutatók jutalmat kapnak a kernel hibák felfedezéséért és kihasználásáért. A teljes technikai részletek a nyilvános írásában olvashatók. Jelenleg nincs bizonyíték arra, hogy a Bad Epoll-t valós támadásokban használták volna: nem szerepel a CISA Known Exploited Vulnerabilities listáján, és a működő exploit kód a kernelCTF proof-of-conceptre korlátozódik.

Miért nem találta meg a Mythos az „ikertestvér” hibát?

A történet egyik tanulságos része, hogy ugyanaz az AI modell, amelyik az első epoll hibát megtalálta, a Bad Epoll-t nem vette észre. Chung két valószínű magyarázatot említ, hangsúlyozva, hogy teljes bizonyossággal senki sem tudja a választ:

• Extrém szűk időablak – a versenyhelyzet olyan rövid időtartományban következik be, hogy még a kódot olvasva is nehéz intuitívan „látni” a pontos eseménysorrendet. Ez embernek és AI-nak egyaránt kihívás.
• Kevés futásidejű bizonyíték – miután az első hibát kijavították, a Bad Epoll által okozott memória-hiba általában nem aktiválja a KASAN-t (Kernel Address Sanitizer), amely a kernel egyik fő hibadetektora. Ha a diagnosztikai eszközök nem jeleznek problémát, az AI-nak is kevesebb kapaszkodója van.

Ez jól mutatja, hogy a versenyfeltételes hibák továbbra is a legnehezebben felfedezhető és kezelhető kategóriába tartoznak – még akkor is, ha fejlett AI eszközök segítik a kutatást.

Mely kernelt érinti, és hogyan javítható?

A Bad Epoll a Linux 6.4-es és annál újabb kernelverziókban jelent meg, mivel a hibát okozó epoll módosítás ekkor került be. A 6.1-es és régebbi kernelvonalak – amelyekre sok LTS disztribúció és Android kiadás épül – nem érintettek, amennyiben nem backportolták a problémás változtatást.

A javítás az upstream kernelben az alábbi commit formájában érhető el:

• a6dc643c6931 – ezt a commitot kell alkalmazni, vagy megvárni, amíg a disztribúció backportolja a saját kernelcsomagjába.

Mivel az epoll nem kapcsolható ki, és nincs érdemi konfigurációs workaround, a gyakorlati tanács a következő:

• ellenőrizni, hogy a rendszer 6.4-es vagy újabb kernelre épül-e,
• ha igen, frissíteni a disztribúció által biztosított legújabb kernelre,
• Android esetén megvárni a gyártó vagy a Google biztonsági frissítését, amely tartalmazza a javítást.

Linux Mint és más desktop disztribúciók esetén ez tipikusan a disztribúció által szállított „HWE” (Hardware Enablement) vagy „security” kernel ágra való frissítést jelenti. Szervereken – különösen felhős környezetben – érdemes figyelni a disztribúció biztonsági értesítéseit (pl. Debian/Ubuntu Security Announce, Red Hat errata), és ütemezetten telepíteni a kernel frissítéseket, akár élő patching (kpatch, ksplice) segítségével, ha az adott környezet ezt támogatja.

„Rossz év” a kernelnek: Bad Epoll és a többi nagy sebezhetőség

A Bad Epoll egy már jól ismert „családba” illeszkedik: a kernel hibák közé, amelyekkel Android root szerezhető. Ide tartoznak a korábbi, beszédes nevű sebezhetőségek is, mint a Bad Binder, Bad IO_uring és Bad Spin. Ezek mind a kernel egy-egy erősen használt alrendszerét célozták, és több esetben valós támadásokban is megjelentek.

Az utóbbi időszakban különösen sűrűn jelentek meg privilégium-eszkalációs hibák a Linux kernelben, de ezek többsége technikailag eltér a Bad Epoll-tól. A Copy Fail (CVE-2026-31431) például már felkerült a CISA Known Exploited Vulnerabilities listájára, vagyis aktívan kihasznált hibáról van szó. Ezt követte több, úgynevezett Dirty Pipe-szerű lánc, mint a Dirty Frag, Fragnesia, DirtyClone és a pedit COW.

Ezek közös jellemzője, hogy determinista page-cache írási hibák, hasonlóan a 2022-es Dirty Pipe-hoz: nincs bennük versenyfeltétel, a támadás lépései megbízhatóan, kiszámíthatóan végrehajthatók. Ez a gyakorlatban azt jelenti, hogy sokkal stabilabb és könnyebben kihasználható exploitokat lehet rájuk építeni, amelyek akár egyetlen próbálkozással is sikerrel járnak.

A Bad Epoll ezzel szemben a „régi iskola” kategóriájába tartozik, a Dirty Cow (2016) típusú hibákhoz hasonlóan: itt versenyt kell nyerni a kernelben, ami önmagában nehezebb, és általában több próbálkozást, kifinomult időzítést igényel. A Chung által elért 99%-os sikerességi arány éppen ezért technikailag figyelemre méltó, de nem változtat azon, hogy a hiba alapvetően versenyfeltételes jellegű.

FUSE, Bynario és más AI által talált hibák

A Bad Epoll nem az egyetlen friss kernel sebezhetőség, amely mögött AI-alapú kutatás áll. Nyilvánosságra került egy másik hiba is, a CVE-2026-31694, amely a kernel FUSE (Filesystem in Userspace) kódjában található. Ezt a Bynario nevű, AI-vezérelt kutatócég azonosította.

A FUSE lehetővé teszi, hogy fájlrendszerek felhasználói térben fussanak, miközben a kernel egy speciális interfészen keresztül kommunikál velük. A CVE-2026-31694 esetében egy helyi felhasználó, aki rendelkezik FUSE hozzáféréssel, rosszindulatú fájlrendszert tud a kernelnek „tálalni”, amely memória-korrupcióhoz vezethet. A következmények a környezettől függően:

• root jogosultság megszerzése,
• adatkiszivárgás,
• vagy egyszerű kernel crash.

Mivel FUSE-t gyakran használják konténerekben és user namespace-ekben, ez a hiba elsősorban szerver- és konténerkörnyezetben jelent komoly kockázatot, kevésbé pedig mobiltelefonokon. A tipikus minta itt az, hogy egy izolált környezetből (konténer, unprivileged user namespace) próbálnak kitörni a host kernelbe, kihasználva a FUSE és a namespace-ek közötti határfelületet.

Anthropic és más szereplők AI modelljei nem csak Linuxon dolgoznak: a Mythos például egy 17 éves távoli kódfuttatási hibát is talált a FreeBSD NFS szerverében (CVE-2026-4747). Ez jól mutatja, hogy az AI-val támogatott kutatás képes régi, évek óta rejtőző hibákat is felszínre hozni, olyan kódbázisokban, amelyeket korábban már számos emberi audit érintett.

Mit tanít a Bad Epoll az AI-ról és a kernel biztonságról?

A Bad Epoll jó ellenpélda arra az elképzelésre, hogy az AI hamarosan „mindent” megtalál. A történet több tanulsággal szolgál:

• A versenyfeltételes hibák továbbra is nehezek – nehéz őket megtalálni (még AI-val is), nehéz őket helyesen javítani (az első patch gyakran nem elég), és nehéz őket stabilan kihasználni (szűk időablak, nem determinisztikus viselkedés).
• Az AI és az emberi kutató kiegészítik egymást – a Mythos megtalálta az első epoll hibát, de a másodikat nem; Chung emberi intuícióval és célzott analízissel rábukkant a „testvér” problémára. Ez arra utal, hogy a jövőben is hibrid megközelítésre lesz szükség.
• A diagnosztikai eszközök nem mindenhatók – ha egy hiba nem aktiválja a KASAN-t vagy más sanitizert, akkor a statikus és dinamikus analízis is nehezebb, legyen az emberi vagy gépi. A Bad Epoll tipikusan ilyen „csendes” hiba volt az első patch után.

A kernel fejlesztők számára a Bad Epoll emlékeztető arra, hogy egy-egy komplex alrendszer – mint az epoll – módosítása láncreakciót indíthat el: egyetlen patch több, egymással összefüggő sebezhetőséget is bevezethet. A biztonsági közösség számára pedig azt jelzi, hogy a kombinált megközelítés – AI + emberi review + formális eszközök + fuzzing – továbbra is szükséges, ha a kernelhez hasonló, nagy és kritikus kódbázisokat akarunk biztonságosabbá tenni.

Felhasználói oldalról a legfontosabb üzenet egyszerű marad: rendszeresen frissíteni kell a kernelt, különösen desktopon, szerveren és Androidon. A Bad Epoll jelenlegi tudásunk szerint még nem terjed a vadonban, de a kernel sebezhetőségek története azt mutatja, hogy a publikus exploit és a valódi támadások között gyakran csak idő kérdése a távolság. Linux Mint és más disztribúciók felhasználóinak ezért érdemes figyelniük a kernelcsomagok biztonsági frissítéseit, és nem halogatni azok telepítését – különösen akkor, ha a rendszer 6.4-es vagy annál újabb kernelverziót futtat, ahol a Bad Epoll ténylegesen jelen lehet.