Amikor a Linux rendszergazdák már épp kezdték maguk mögött hagyni a DirtyFrag ügyét, egy újabb, szorosan kapcsolódó kernel hiba került előtérbe, ami jól mutatja, hogy a történetnek még nincs vége. A JFrog biztonsági kutatói nyilvánosságra hozták a DirtyClone nevű, új Linux kernel helyi jogosultságkiterjesztési sebezhetőséget, amelyet CVE-2026-43503 azonosítóval követnek.

Bár ugyanabba a hibakategóriába tartozik, mint a DirtyFrag, a DirtyClone a kernel hálózati kódjának egy másik útvonalát használja ki. Ez arra utal, hogy a korábbi javítások nem zárták le teljesen ezt a támadási felületet.

A sebezhetőség CVSS pontszáma 8,8, ami magas súlyossági szintnek számít. Jó hír, hogy távolról nem lehet kihasználni; a támadónak helyi hozzáférésre vagy nem privilégizált felhasználóként futtatható kódra van szüksége.

Ha azonban a támadó megszerzi a helyi hozzáférést, a hatás már komoly. A DirtyClone lehetővé teszi a root szintű jogosultságkiterjesztést, és bizonyos esetekben konténerből való kitörésre is alkalmas lehet.

A probléma abból ered, ahogyan a Linux kernel kezeli a socket buffer fragmentumokat. Néhány segédfüggvény nem őrzi meg azt a jelölőt, amely megmutatja, hogy egy csomagtöredék megosztott vagy fájl-alapú memóriát használ. Jelölő nélkül a kernel későbbi részei tévesen biztonságosnak tekinthetik a memóriát közvetlen módosításra.

Bizonyos feltételek mellett a támadó ezt a viselkedést kihasználva módosíthatja a kernel page cache-ben lévő adatokat. Így meg tudja változtatni egy root tulajdonában lévő, csak olvasható fájl memóriában lévő változatát anélkül, hogy a lemezen tárolt fájl módosulna.

A támadáshoz a hálózattal kapcsolatos kernel funkciók elérésére van szükség, különösen az XFRM/IPsec kezelésével és a socket buffer fragmentumokkal összefüggő részekre. A JFrog kiemeli, hogy azok a rendszerek különösen veszélyeztetettek, ahol engedélyezve vannak az unprivileged user namespace-ek, mert ilyen környezetben a CAP_NET_ADMIN-hez hasonló képességek is elérhetővé válhatnak.

Nem minden Linux rendszer egyformán érintett. A kockázatot több tényező befolyásolja: a kernel verziója, a disztribúció által beépített javítások, az engedélyezett funkciók és a biztonsági keményítés mértéke. A sebezhetőség azonban komoly, és nem érdemes pusztán elméleti problémának tekinteni.

A névhasználat is okozhat némi zavart. Ubuntu a hibát Fragnesia néven említi, míg a JFrog a kihasználási változatra a DirtyClone nevet használja. A gyakorlatban mindkét elnevezés ugyanarra, a CVE-2026-43503 azonosítójú hibára utal, csak eltérő nézőpontból.

Ubuntu több támogatott verzióhoz is kiadta a javításokat az általános Linux kernel-hoz. A szokásos Ubuntu kernel esetén a javított verziók a következők:

• Ubuntu 26.04 LTS: javítva a 7.0.0-22.22 verzióban
• Ubuntu 25.10: javítva a 6.17.0-35.35 verzióban
• Ubuntu 24.04 LTS: javítva a 6.8.0-124.124 verzióban
• Ubuntu 22.04 LTS: javítva az 5.15.0-181.191 verzióban

A felhős és speciális kernel változatok külön státuszfrissítést kaptak. Akik AWS, Azure, GCP, Raspberry Pi, valós idejű, OEM vagy más, nem általános kernel-t használnak, mindig a saját csomagjuk állapotát ellenőrizzék, ne az általános kernel-ra vonatkozó információkra hagyatkozzanak.

Debian és a Red Hat szintén követi a hibát. Debian security tracker oldalán több ághoz is felsorolják a javított verziókat, köztük a Bullseye, Bookworm és Trixie kiadások frissítéseit.

Eközben a Red Hat a Dirty Frag és a kapcsolódó változatok esetét a hálózati alrendszert érintő jogosultságkiterjesztési problémaként kezeli. Tanácsuk a teljes Dirty Frag családra kiterjed, és kiemeli, hogy egy helyi felhasználó a hibákat kihasználva root jogosultságot szerezhet.

Mit tegyenek a felhasználók? A javasolt megoldás, hogy telepítsék a legfrissebb kernel frissítéseket a disztribúciójukból, majd indítsák újra a rendszert.

Az újraindítás elengedhetetlen. Önmagában a kernel frissítés telepítése nem elég, ha a rendszer továbbra is a régi, sebezhető kernel-t futtatja. A javított kernel csak újraindítás után lép működésbe.

Ha az azonnali javítás nem megoldható, ideiglenes enyhítésként szóba jöhet az unprivileged user namespace-ek letiltása, vagy az érintett kernel modulok – például az esp4, esp6 és rxrpc – blokkolása. Ezek a kerülőmegoldások azonban zavarhatják a legitim működést, különösen az IPsec VPN-eket vagy az AFS/RxRPC-t használó rendszereket, ezért csak körültekintően érdemes alkalmazni őket.