Az ARM64-es virtuális gépek ritka beállítása mögött komoly Linux-kockázat van

Egy ARM64-es Linux-gazdagépen futó virtuális gép elvileg szigorúan elkülönül a befogadó rendszertől. A CVE-2026-89775 azonosítójú hiba éppen ezt a határt veszélyeztetheti: meghatározott feltételek mellett a vendég virtuális gép írhatja és olvashatja a gazdagép rendszermemóriájának egy részét. A kutatást bejelentő Hyunwoo Kim szerint ez akár a virtuális gépből való kitöréshez, vagyis a gazdagépen futó kód eléréséhez is felhasználható.

A probléma nem az átlagos ARM64-es Linux-rendszerek tömeges hibája. Csak akkor nyílik meg a leírt támadási út, ha a KVM virtualizációban engedélyezett a beágyazott virtualizáció. Ez ARM64-en alapértelmezetten ki van kapcsolva, kísérleti indításkori funkciónak számít, és Armv8.4-es hardvert, valamint FEAT_NV2 támogatást igényel. Mégis jó példája annak, hogy egy ritkán használt, de technikailag hasznos képesség miként hozhat magával aránytalanul nagy biztonsági felelősséget.

Mi történik a memóriában?

A KVM a Linux kernel azon része, amely lehetővé teszi virtuális gépek futtatását. A beágyazott virtualizáció ennél egy lépéssel tovább megy: a vendég gép saját virtualizációs környezetet is üzemeltethet, tehát virtuális gépen belül is lehet virtuális gép.

A hiba ebben az ARM64-es KVM-kódrészben található. Egy speciális memóriaelrendezésnél egy méretszámítás nullára futhat, ezért kimarad egy szükséges TLB-invalidation. A TLB a processzor gyors címtára: azt tartja nyilván, hogy a programok által használt memóriacímek valójában hová mutatnak. Ha az elavult bejegyzések törlése elmarad, egy már felszabadított gazdagépmemória-lap továbbra is leképezve és írhatóként maradhat a vendég számára.

A jelentés szerint a vendég ebből a memóriából 64 bites egységekben olvashat és írhat, anélkül hogy a hardver visszaadná az irányítást a gazdarendszernek. Ez magyarázza, miért értékelik a hatást súlyosnak a gyártók: a sérülékenység pont azt az elszigetelést kezdheti ki, amelyért a virtuális gépeket használják.

Nem minden érintettnek látszó kernel egyformán veszélyeztetett

A kernel nyilvántartása alapján az érintett kód Linux 6.16-tól jelen van. A javítást ellenőrző karbantartó ugyanakkor arra jutott, hogy a kihasználáshoz szükséges, elmaradó érvénytelenítés csak a 6.17-es verziótól kezdődik. Eszerint egy 6.16-os gazdagépben lehet hasonló kódrészlet, de nem feltétlenül áll fenn az a viselkedés, amelyre a támadás épülne.

A javítás az upstream Linuxban a 6.18.51, 7.2.5 és 7.3-rc1 verziókban szerepel. A Linux-disztribúciók saját ütemben adják ki a frissítéseket, ezért egy adott szervernél a használt disztribúció biztonsági közleménye és a tényleges kernelverzió a döntő. A Red Hat a 10-es verziójú kernelét érintettként sorolja fel, míg a 6–9-es kiadásokat nem érintettként jelzi.

A funkció haszna és az elkülönítés ára

A beágyazott virtualizáció nem öncélú különlegesség. Fejlesztési, tesztelési és egyes infrastruktúra-helyzetekben arra szolgálhat, hogy egy már virtualizált környezetben is lehessen virtualizációt használni. Aki ilyen rendszert üzemeltet, annak ez rugalmasabb kialakítást adhat.

Ugyanez a rétegzettség azonban több hibalehetőséget is teremt. Itt nem arról van szó, hogy a virtualizáció általában megbízhatatlan lenne, hanem arról, hogy az alapértelmezetten kikapcsolt, kísérleti funkció bekapcsolásakor új feltételeket kell ellenőrizni: a hardvert, a kernelverziót, a hozzáférési jogosultságokat és a javítások állapotát is.

A kutató egy másik helyzetre is felhívta a figyelmet. Ha egy helyi felhasználó megnyithatja a /dev/kvm eszközt, amelyen keresztül programból virtuális gép hozható létre, a hiba elméletben jogosultságemeléshez is vezethet. Ez is csak engedélyezett beágyazott virtualizáció mellett releváns. Red Hat Enterprise Linuxon a kutató szerint az eszköz alapból minden felhasználó számára elérhető.

A nagy felhőknél sem ugyanaz a helyzet

A sérülékenység kapcsán kézenfekvő kérdés a felhős környezetek biztonsága. A leírt út azonban nem jelenik meg a legnagyobb szolgáltatók szokásos ARM-ajánlataiban: az Amazon Web Services beágyazott virtualizációt csak Intel-alapú példányoknál sorol fel, a Google Cloud pedig ARM virtuális gépeinél kizárja ezt a lehetőséget. Ez nem általános biztonsági bizonyítvány ezekre a platformokra, csak azt jelenti, hogy a hiba konkrét feltétele ott nem adott a megszokott ARM-konfigurációkban.

Szeptember 22-ig nem volt jel arra, hogy a hibát támadásban használták volna, és nyilvános kihasználókód sem jelent meg. A gyártói kockázati pontszámok 7,8 és 9,3 között mozognak tízből; abban egyetértenek, hogy a hatás nagy lehet, de a támadás helyi hozzáférést igényel, nem indítható egyszerűen hálózaton keresztül.

A gyakorlati kérdés ezért nem az, hogy mindenütt le kell-e mondani a beágyazott virtualizációról. Inkább az, hogy egy ritkán használt, kísérleti funkció nyújtotta rugalmasság indokolja-e a folyamatosabb frissítési és jogosultsági ellenőrzést: ön szerint mikor éri meg egy üzemeltetőnek bekapcsolva hagynia ezt az ARM64-es képességet?