Een use-after-free bug in de SCTP-netwerkcode van Linux kan worden omgezet in volledige root op een host, en onderzoekers van Tencent zeggen dat ze deze hebben gebruikt om uit een container te ontsnappen en de machine eronder te bereiken.
De fout bestaat al sinds 2008. De oplossing is al verzonden: stabiele kernels 7.1.6, 6.18.42, 6.12.101 en 6.6.148, uitgebracht op 3 augustus, sluit deze. Iedereen die een oudere kernel draait waarbij SCTP bereikbaar is, zou moeten updaten.
Bijgehouden als CVE-2026-64564 en benoemd SCT Phantom door de vinders werd de fout publiekelijk bekendgemaakt op 6 augustus, twee dagen nadat het kernel CVE-team de fout had toegewezen. Op het moment van schrijven was er nog geen openbare exploitcode opgedoken, en The Hacker News vond vanaf 7 augustus geen vermelding voor de fout in CISA’s Known Exploited Vulnerabilities-catalogus.
De fout is lokaal, niet op afstand, en er is SCTP nodig die op het doel bereikbaar is, wat de blootstelling beperkt. Waar deze voorwaarden van toepassing waren, meldt Tencent Zhuque Lab dat het root is geworden op de kernelbuilds die het heeft getest voor Debian 13, Ubuntu 24.04, Rocky Linux 9 en RHEL 9, en OpenCloudOS.
SCTP is een transportprotocol waarmee één verbinding over meerdere netwerkpaden tegelijk kan lopen. Een begeleidende functie, dynamische adresherconfiguratie, zorgt ervoor dat een peer deze adressen tijdens de verbinding kan toevoegen of verwijderen.
De bug is een verwarring over de identiteit: de kernel controleert een verwijderingsverzoek aan de hand van het bronadres van het pakket, maar handelt op een pad dat hij heeft gekozen door een ander adres in het bericht te gebruiken. Volgens het eigen advies van de kernel kan één bericht een adres bevatten, een verwijdering voor datzelfde adres en vervolgens een verwijdering met een jokerteken. Die reeks maakt het pad vrij en gebruikt vervolgens de dode aanwijzer opnieuw, waardoor de verbinding naar het geheugen wijst dat de kernel al heeft vrijgegeven.
De patch weigert een verwijdering gericht op het pad waartegen het bericht wordt verwerkt. De bug is terug te voeren op Linux 2.6.25 uit 2008 en zit in elke kernel die sindsdien is uitgebracht.
De ontsnappingsclaim van Tencent voor containers is gebaseerd op eigen tests. In zijn artikel zegt het lab dat voor een vroege versie van zijn exploit de net.sctp.addip_enable en net.sctp.addip_noauth_enable sysctls ingeschakeld moesten zijn, waardoor CAP_NET_ADMIN op een vereiste leek. Later vond het een route die beide onaangetast laat door in plaats daarvan de functies per socket in te schakelen.
Het laboratorium zegt dat de ontsnappingstest het standaard seccomp-profiel heeft behouden en noch CAP_NET_ADMIN noch CAP_SYS_ADMIN heeft toegekend. Volgens de telling bereikten zes van de acht pogingen wortel op de host.
Niemand buiten het laboratorium heeft iets daarvan gereproduceerd, en het artikel vermeldt niet tegen welke containerruntime het heeft getest. Het lab merkt zelf op dat sockettoegang, seccomp-profielen en gebruikersnaamruimtebeleid allemaal de blootstelling elders verschuiven. Een openKylin-advies over dezelfde bug gaat niet verder dan kernelpaniek en denial of service.
Ook het ernstnummer is onzeker. Tencent scoorde een 8,5 onder CVSS v4.0. NVD had vanaf 7 augustus geen score of zwakteclassificatie toegekend.
Leveranciers backporteren vaak fixes zonder naar een nieuwe upstream-versie te verhuizen, dus een kernelversiestring alleen zal je niet vertellen of je gedekt bent; controleer de tracker van uw distributie. Een tweede bungelende transport-use-after-free in dezelfde code werd op 6 augustus gepatcht, nadat de stabiele releases van 3 augustus waren verzonden, dus die kernels bevatten dit niet. Waar SCTP niet nodig is, verwijdert het blokkeren van de module het aanvalsoppervlak regelrecht.
Tencent schrijft de vondst toe aan Corvus AI, een multi-agent onderzoekspijplijn die het heeft gebouwd voor kernelwerk, waardoor SCTphantom de nieuwste is in een reeks lang sluimerende kernelfouten die dit jaar met machine-ondersteuning aan het licht zijn gekomen, naast GhostLock in juli. Het landt ook op dezelfde dag als Zapscape, een niet-gerelateerde KVM-ontsnapping, en dezelfde vier stabiele releases bevatten beide oplossingen.
