CVE-2026-98432: Linux TCP-hiba, Ubuntuhoz és RHEL-hez nincs javítás

Megjelent · Biztonsági figyelmeztetés · Papp Ferenc

A CVE-2026-98432 a Linux kernel IPv4-es TCP-kapcsolatainak felépítésekor jelentkező hiba: bizonyos műveletek időzítése miatt a kernel már felszabadított memóriát használhat (use-after-free). A hiba a Linux 4.4 óta jelen van, és a kernel CVE-csapatától 9,8-as súlyossági pontszámot kapott. Az Anthropic szerint egy még nem publikált kutatási modelljük olyan exploitot írt hozzá, amellyel a támadó távolról, hitelesítés nélkül root shellhez juthat, ha a szerver multipath TCP-s (MPTCP) kapcsolatokat fogad. Október 30-án az Ubuntuhoz és a Red Hat Enterprise Linuxhoz még nincs javított kernel, a Debian, az Oracle Linux, a SUSE és az Amazon Linux viszont már kiadott egyet, legalább néhány verzióhoz.

Ha VPS-en vagy dedikált gépen futtatsz Laravelt, Symfonyt vagy bármi mást, a kernel frissítéséről is gondoskodnod kell. Én ezzel nem várnék holnapig.

Röviden

  1. Futtasd le a uname -r parancsot minden internetről elérhető szerveren, és nézd meg, van-e a disztródhoz javított kernel (lista lent).
  2. Ha van, telepítsd, és indítsd újra a gépet. A javítás akkor lép életbe, amikor már az új kernel fut.
  3. Ha nincs (Ubuntu, RHEL), még nem tudsz javítani. Zárd le a feleslegesen nyitott portokat, ellenőrizd az MPTCP-t használó szolgáltatásokat, és nézd meg a lentebb leírt ideiglenes tűzfalszabályt.
  4. Holnap nézd meg újra a gyártó oldalát. Mindkét cég dolgozik rajta, megjelenési dátumot viszont egyik sem közölt.

Mit tudunk, és mit nem?

A kernel egy még felépülő kapcsolat IP-opcióit másolás nélkül átadja az új socketnek. Ha ezt a socketet megszüntetik, miközben egy másik CPU még ugyanezekkel az opciókkal válaszol egy újraküldött kapcsolatkérésre, a kernel felszabadított memóriát olvas. IPv6-on ez a versenyhelyzet nem fordul elő. A javítás annyit tesz, hogy a kernel megvárja, amíg egyetlen CPU sem használja az opciókat, és csak utána szabadítja fel őket.

Az Anthropic két lépésben használta ki a hibát. Először egy kernelbeli memóriacímet szerzett meg, amivel megkerülte a memóriacímeket véletlenszerűsítő KASLR-védelmet. Ezután ugyanazzal a hibával felülírt egy függvénymutatót, így a kernel root jogosultsággal futtatta le a támadó parancsát. Ha az időzítés nem sikerül, csak az adott kapcsolat szakad meg, a támadó újra próbálkozhat. A tesztben 48 perc kellett a memóriacím megszerzéséhez, majd további öt perc a parancsfuttatáshoz. Az exploit kódját nem tették közzé.

A leírások között vannak eltérések, és néhány kérdés még nyitott:

  • MPTCP. Az exploit MPTCP-kapcsolatokat fogadó szervereket céloz, de a CVE-rekord és a kernel javítása sem említi az MPTCP-t. Ezt a feltételt az Anthropic írja le a saját exploitjánál. A Go biztonsági csapata szerint maga a hiba nem MPTCP-specifikus, és hasonló támadás az MPTCP-t nem használó rendszereken is működhet.
  • Támadások. Az általam olvasott közleményekben senki nem ír éles kihasználásról, és a The Hacker News szerint október 28-án a hiba nem szerepelt a CISA aktívan kihasznált sérülékenységeket nyilvántartó listáján. Ez gyorsabban változhat, mint ahogy ezt a cikket frissíteni tudom.
  • A pontszám. A kernelcsapat szerint a támadás kevéssé összetett, mert a versenyhelyzet mindkét műveletét a támadó indítja el; ezért adnak rá 9,8-at. A Red Hat, az Oracle és a SUSE összetettebbnek ítéli a támadást, így náluk 8,1 a pontszám. Az Amazon 7,0-ra értékeli, a Red Hat saját oldalai pedig a The Hacker News szerint egy napig ellentmondtak egymásnak. Én nem töltenék ezzel időt. A hibát megtaláló cég azt állítja, hogy az exploit működik és megismételhető, és ez elég ahhoz, hogy előre vedd az internetről elérhető szerverek ellenőrzését.

Kinek van javítása?

Október 30-án ezt írják a gyártók a saját oldalaikon:

  • Debian: javítva. A trixie-ben a linux 6.12.113-1, a bookwormban a linux 6.1.190-1 (a backportolt 6.12-es kernelhez 6.12.113-1~deb12u1).
  • Oracle Linux 7–10 (UEK): október 16-án javították.
  • Amazon Linux 2023: a kernel6.18 és a kernel6.12 csomag javítva, az alapértelmezett kernel csomaghoz még készül a javítás.
  • SUSE: a SUSE Linux Micro 6.2 és az openSUSE Leap 16.0 javítva, a SLES 15-höz és 16-hoz még készítik vagy tesztelik a javítást.
  • Ubuntu 22.04, 24.04, 26.04, 26.10: sérülékeny, a javítás készül. Ubuntu 20.04 és régebbi: sérülékeny, javítás nincs a listán. A felhős, FIPS és valós idejű kernelek is szerepelnek.
  • RHEL 8, 9, 10 és OpenShift 4: érintett, javítás nincs. A Red Hat szerint nem tudnak olyan átmeneti védekezést ajánlani, amely megfelelne a saját követelményeiknek. A RHEL 7 nem érintett.

Ha saját kernelt fordítasz, a javítás az 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 és 7.3 verzióban van benne. A kernelcsapat azt kéri, hogy a legfrissebb stabil kiadásra állj át, ne egyenként szedd össze a patcheket.

Ellenőrizd a szervered

bash
uname -r                                   # a most futó kernel

# Debian / Ubuntu
apt changelog linux-image-$(uname -r) | grep CVE-2026-98432

# RHEL / Alma / Rocky / Oracle Linux
rpm -q --changelog kernel-$(uname -r) | grep CVE-2026-98432

A találat segíthet az ellenőrzésben, de a changelog önmagában nem ad biztos választ. Ha nem szerepel benne a CVE, attól még tartalmazhatja a javítást. A futó kernel csomagverzióját a disztró biztonsági közleményében megadott javított verzióval vesd össze. A frissítés után indítsd újra a gépet, és futtasd le újra a uname -r-t. Ubuntun a /var/run/reboot-required fájl jelzi, hogy újra kell indítani a gépet.

Konténereknél és menedzselt környezetben azt is tisztázd, melyik gépet kell frissíteni:

  • A konténerek a gazdagép kernelét használják. A Docker-image újraépítése itt semmit nem javít, a hoston kell az új kernel.
  • Megosztott vagy menedzselt tárhelyen a kernel a szolgáltatóé. Kérdezd meg tőle egyenesen: „Javítva van a CVE-2026-98432 azon a szerveren, amelyen az oldalam fut?”
  • Kubernetesnél minden csomópontot frissíteni kell. Az újraindításokat egyesével, a terhelés áthelyezésével tervezd meg.

Ha a disztródhoz még nincs javított kernel

Ezek egyike sem pótolja a javítást, és senki nem mutatta meg, hogy bármelyik megállítaná az exploitot. Arra jók, hogy kevesebb helyről lehessen elérni a sérülékeny szolgáltatásokat, amíg vársz.

Zárd le a feleslegesen nyitott portokat. Nézd végig, melyik szolgáltatásodnak kell tényleg elérhetőnek lennie az internetről. Zárd le, ami nem kell, az adatbázist és az adminfelületeket tedd VPN vagy IP-engedélylista mögé, és ahol belefér, tedd az oldalt egy Cloudflare-hez hasonló proxy mögé. A kliens TCP-kapcsolatát a proxy fogadja, így a támadó csomagjai nem jutnak el a kerneledig. Ez viszont csak akkor igaz, ha a mögötte lévő szerver csak a proxytól fogad kapcsolatot, és a portja nincs nyitva mindenki másnak.

Ellenőrizd, melyik szolgáltatás használ MPTCP-t. Az alkalmazás a tudtod nélkül is bekapcsolhatja: a Go 1.24 óta a Go-programok alapértelmezetten MPTCP-t kérnek a hallgatózó socketjeikre.

bash
sysctl net.mptcp.enabled
sudo ss -lnM          # hallgatózó MPTCP-socketek

Go-szolgáltatásoknál a Go csapata a GODEBUG=multipathtcp=0 környezeti beállítást javasolja. Fordításkor a go.mod fájlba írt godebug multipathtcp=0 sorral is kikapcsolhatod az alapértelmezett MPTCP-használatot. Ha a kód a SetMultipathTCP-t hívja, az mindkét beállítást felülírja. A csapat szerint könnyű úgy alkalmazni ezt a védekezést, hogy egy szolgáltatás kimaradjon. A gyártók nem mondták meg, csökkenti-e a kockázatot, ha a kernelben kikapcsolod az MPTCP-t, és egy már megnyitott listener nyitva marad, ha átállítod a sysctl értékét. Én először az MPTCP-t használó szolgáltatásokat keresném meg, de a kikapcsolásától még nem tekinteném védettnek a gépet.

Ideiglenes tűzfalszabály. A hiba kiváltásához IPv4-opciókat tartalmazó kapcsolatkérés kell. Ilyen csomag ritkán fordul elő a hétköznapi internetes forgalomban. Az RFF blogján azt javasolják, hogy a tűzfal dobja el az összes olyan IPv4-es TCP-csomagot, amely IP-opciókat tartalmaz:

bash
sudo nft add table ip cve_2026_98432
sudo nft add chain ip cve_2026_98432 pre '{ type filter hook prerouting priority -300; }'
sudo nft add rule ip cve_2026_98432 pre meta l4proto tcp ip hdrlength gt 5 counter drop

# visszavonás
sudo nft delete table ip cve_2026_98432

A szerző Rocky és Ubuntu virtuális gépeken a hiba kiváltását tesztelte, a teljes exploitot nem, és én magam sem futtattam le. A fenti szabály újraindítás után nem marad meg, az átirányított, IP-opciós forgalmat is eldobja, és CIPSO-címkézést használó hálózaton rossz ötlet. Gyártó nem ajánlja. Én előbb tesztgépen próbálnám ki, és ellenőrizném, nem akadályozza-e a szükséges forgalmat. Csak ezután döntenék arról, hogy az éles szerveren is bevezetem-e.

Ki frissíti és indítja újra a szervert?

Attól, hogy a kernel fejlesztői kiadták a javítást, a disztród csomagtárában még nem feltétlenül lesz ott. A CVE október 15-én lett publikus, a Debian és az Oracle Linux két napon belül kiadott javított kernelt, az Ubuntuhoz és a RHEL-hez viszont két héttel később sincs telepíthető javítás. Ezért érdemes tudni, melyik szervered melyik disztrón fut, ki felel a frissítésért, és mikorra lehet újraindítást szervezni.

Segítsek?

PHP- és Laravel-alkalmazások fejlesztésével és üzemeltetésével foglalkozom. Ha segítség kell a szervered ellenőrzéséhez vagy a kernelfrissítés és az újraindítás megtervezéséhez, írj nekem.

Források

KapcsolatfelvételÖsszes cikk

· Vélemény

Miért nem építek csak Claude-ra?

Így választom le az alkalmazást a Claude-ról és más AI-szolgáltatókról: saját interfésszel, ellenőrző tesztekkel és egy működő tartalék úttal.