CVE-2026-98432: Risico op Linux TCP Use-After-Free en Patch-validatie

Interpretatie van bewijsmateriaal en risico's

Het openbare bewijsmateriaal vereist een zorgvuldige interpretatie. Het Linux CNA-record kent een CVSS 3.1-score van 9.8 toe, met netwerkbereikbaarheid, geen vereiste privileges of gebruikersinteractie, en een hoge potentiële impact op vertrouwelijkheid, integriteit en beschikbaarheid. De openbare advisory van Red Hat en hun officiële machine-leesbare record vermelden een voorlopige CVSS 3.1-score van 8.1. De Red Hat-vector heeft ook een hoge impact op vertrouwelijkheid, integriteit en beschikbaarheid, maar schat de aanvalcomplexiteit in als hoog in plaats van laag.

Afzonderlijk rapporteerde het Frontier Red Team van Anthropic remote root command execution tegen een server met een Multipath TCP (MPTCP)-listener in een gecontroleerd laboratorium. Dit demonstreert ernstige exploiteerbaarheid onder een specifieke configuratie, en niet een universele compromittering van elke Linux TCP-listener.

Verdedigers moeten deze verklaringen als complementair beschouwen:

  • Het upstream-record identificeert een gevaarlijke fout in de levensduur van het geheugen en de theoretisch maximale impact.
  • Een distributiescore beschrijft de door de leverancier geleverde code, configuratie, mitigaties en verwachte exploitatievoorwaarden.
  • Een onderzoeks-exploit demonstreert één concreet pad via een specifiek doelwit.

Praktische respons

De praktische reactie is direct: identificeer bereikbare Linux TCP-services, bepaal welke kernel van de leverancier daadwerkelijk wordt gebruikt, installeer de door de leverancier verstrekte vaste build, herstart het systeem en bewaar bewijs dat de actieve kernel de correctie bevat.

Hosts die MPTCP-listeners openstellen, verdienen onmiddellijke aandacht omdat het openbare onderzoek specifiek die omgeving heeft gevalideerd. Internet-facing gateways, loadbalancers, Kubernetes-nodes, VPN-endpoints, reverse proxies en appliances die Linux-netwerking gebruiken, verdienen ook een snelle inventarisatie, zelfs als ze MPTCP niet bewust hebben ingeschakeld.

Voor beheerders die zoeken naar CVE-2026-98432 op AlmaLinux of Ubuntu, moet de pakketstatus worden gecontroleerd tegen de exacte distributie-release en kernel-variant. De status van AlmaLinux kon in deze onderzoekssnaphot van 30 oktober 2026 niet onafhankelijk worden bevestigd via een officiële CVE-specifieke advisory; Ubuntu publiceert een live tracker per pakket. Interpreteer het ontbreken van een advisory niet als bewijs van veiligheid.

Technische details van CVE-2026-98432

De autoritaire technische beschrijving komt voort uit het Linux kernel CVE-proces en de upstream patch. Het probleem betreft het eigendom en het terugvorderen van IPv4-optiegegevens die geassocieerd zijn met een TCP-request-socket.

Tijdens de serverzijde van een TCP-handshake maakt de kernel een lichtgewicht request-socket aan om een verbinding te representeren die nog geen volledige child-socket is geworden. Wanneer de handshake vordert, draagt tcpv4synrecvsock() de ireqopt-pointer van de request over naar de nieuwe child-socket als inetopt. Het object wordt hierbij niet gedupliceerd.

Tegelijkertijd kan een andere CPU een opnieuw verzonden SYN verwerken die geassocieerd is met dezelfde request. Dat tweede pad kan een andere SYN-ACK verzenden via tcpcheckreq(). Functies zoals tcpv4sendsynack() en inetcskroutereq() lezen de IP-opties van de request binnen een RCU (Read-Copy Update) read-side kritieke sectie. Latere helpers, waaronder ipbuildandsendpkt() en ipoptionsbuild(), derefereren velden uit het optie-object.

De kern van het probleem: mismatch in levensduur

Het kernprobleem is de mismatch in de levensduur. De lezer gaat ervan uit dat RCU het object beschermt, maar de destructor geeft het vrij met een gewone kfree(). Een gewone kfree() maakt de allocatie direct beschikbaar voor hergebruik zonder te wachten tot bestaande RCU-lezers klaar zijn. Als de child-socket wordt vernietigd terwijl een pad voor een opnieuw verzonden SYN nog steeds de opties gebruikt, kan de tweede CPU geheugen blijven lezen dat niet langer toebehoort aan dat object.

De primaire upstream-fix vervangt het onmiddellijke vrijgeven door kfree_rcu() in de relevante destructors, waardoor het terugvorderen wordt uitgesteld tot een RCU-grace-periode is verstreken.

Request-migratie en IPv6

De kwetsbaarheid heeft ook een gerelateerde case bij request-migratie. Als net.ipv4.tcpmigratereq=1 is ingeschakeld, of als een BPFSKREUSEPORTSELECTORMIGRATE-programma de request-migratie bestuurt, kan de kernel een request-socket klonen. De oude request en zijn kloon kunnen tijdelijk hetzelfde optie-object delen. Een CPU die een referentie naar de oude request vasthoudt, kan het object nog steeds gebruiken terwijl de kloon wordt vrijgegeven. Daarom past de kernel zowel inetsockdestruct() als tcpv4reqskdestructor() aan om RCU-bewust terugvorderen te gebruiken.

Het eerste probleem is specifiek voor het IPv4 child-socket-pad, omdat de overeenkomstige IPv6-functie opties dupliceert in plaats van dezelfde pointer over te dragen. De upstream-tekst merkt ook een IPv6 request-migratieprobleem op met betrekking tot ipv6_opt wanneer CALIPSO aanwezig is, en stelt dat deze conditie apart wordt afgehandeld. Een bewering dat "IPv6 niet is getroffen" is dus te breed, terwijl een bewering dat de hoofd-bug van de IPv4-eigendomsoverdracht niet van toepassing is op het gewone IPv6 child-creation-pad accuraat is.

De patch is upstream samengevoegd als commit e3f33b0a1d89, getiteld "ipv4: free inetopt and ireqopt after an RCU grace period".

Feiten die niet zijn vastgesteld

Er is geen autoritair bewijs dat wijst op wijdverspreide exploitatie over het openbare internet. Anthropic stelde vast dat hun onderzoekers de fout konden omzetten in remote root command execution tegen een gecontroleerd doelwit met een MPTCP-listener. Hoewel dit sterker is dan een crash-only bewijs, bewijst het niet de prevalentie van kwetsbare MPTCP-services of een universeel succespercentage over verschillende kernel-builds, CPU-architecturen of hardening-profielen.

Daarnaast is er geen rechtvaardiging om aan te nemen dat elk hoog volume aan SYN-retransmissies wijst op exploitatie. Retransmitted SYN-pakketten komen natuurlijk voor door pakketverlies, asymmetrische routing of overbelaste services.

Er is geen enkele upstream-versieaanduiding die elk vendor-kernel accuraat labelt. Enterprise-distributies backporten routinematig beveiligingsfixes terwijl ze een oudere basisversie behouden. Een scanner die alleen uname -r vergelijkt met een upstream-lijst, kan zowel vals-positieven als vals-negatieven produceren.

Ten slotte verwijdert het uitschakelen van MPTCP de onderliggende IPv4-levensduur-bug niet. Het verwijdert enkel de specifieke listener-configuratie die in het openbare onderzoek is gebruikt.

Hoe het kwetsbare TCP-pad werkt

Een TCP-server ontvangt normaal gesproken een SYN, antwoordt met SYN-ACK en wacht op de laatste ACK. Om resources te sparen, maakt de kernel bij het eerste pakket geen volledige verbonden socket aan, maar een compacte request-socket. Wanneer de ACK arriveert en de verbinding wordt geaccepteerd, maakt de kernel een volledige child-socket aan en verplaatst of kopieert geselecteerde statusgegevens hiernaartoe.

IPv4-opties compliceren deze overgang. In het getroffen pad wordt de ireqopt-pointer van de request-socket de inetopt-pointer van de child-socket. Deze overdracht voorkomt een kopie, maar betekent dat de levensduur van één allocatie de grens tussen twee socket-objecten overschrijdt.

Wanneer een tweede SYN voor dezelfde verbinding arriveert voordat de handshake is voltooid, kan de kernel deze op een andere CPU verwerken en een SYN-ACK bouwen met de oorspronkelijke request-socket. Omdat Linux-netwerking sterk parallel is, kan de child-socket al worden afgebroken terwijl de andere CPU nog steeds het antwoord construeert. Het request-pad neemt een RCU-read-lock, wat aangeeft dat de gegevens geldig moeten blijven tot de kritieke sectie eindigt.

Het oude gedrag van de destructor schond deze verwachting: de child-socket had geen SOCKRCUFREE-gedrag en inetsockdestruct() gaf inet_opt direct vrij. De tweede CPU kon de pointer behouden en optlen lezen uit geheugen dat al was teruggegeven aan de allocator.

Use-after-free bugs zijn gevaarlijk omdat het symptoom afhangt van wat de vrijgegeven allocatie vervangt:

  • Het kan onschadelijk lijken als oude bytes worden gelezen.
  • Het kan leiden tot een crash bij het tegenkomen van poisoned of niet-gemapte geheugen.
  • Het kan data onthullen als een nieuw kernel-object wordt gelezen.
  • Bij voldoende controle over allocatiepatronen en timing kan een onderzoeker de referentie omzetten in een krachtige lees-, schrijf- of control-flow primitief.

De variant met request-migratie volgt hetzelfde principe via een andere topologie. Reuseport staat meerdere sockets toe om een luisterpoort te delen. Request-migratie kan lopende verbindingen verplaatsen wanneer een listener van status verandert. Hierdoor ontstaat een venster waarin twee request-objecten refereren aan dezelfde optie-allocatie. Als de destructor van het ene object de gedeelde allocatie direct vrijgeeft, wordt de lezer in het andere object stale.

Waarom RCU de veiligheidsgrens verandert

Read-Copy Update (RCU) stelt lezers in staat om gedeelde gegevens te benaderen met zeer lage overhead, terwijl schrijvers vervangingen publiceren en het vrijgeven van oude versies uitstellen. Een schrijver kan het object verwijderen uit de datastructuur, maar moet wachten op een grace period voordat het geheugen wordt teruggevorderd. Dit garandeert dat alle lezers die de oude pointer konden hebben gezien, klaar zijn.

In CVE-2026-98432 gebruiken de read-paden al RCU. De correctie zorgt ervoor dat de destructor dit contract respecteert. kfree_rcu() plant het object in voor release na een grace-periode in plaats van het onmiddellijk vrij te geven. Dit ontwerp behoudt concurrency zonder dat de server hoeft te stoppen met het verwerken van retransmissies of grote locks rond de handshake-constructie hoeft te plaatsen.

Analyse van de CVSS-scores

Er is een verschil in scores tussen instanties:

  • Linux CNA: CVSS 3.1 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). Gaat uit van lage aanvalcomplexiteit.
  • Ubuntu: Toont 9.8, maar publiceert ook een CVSS 4.0 assessment van 8.3 met aanvalsvereisten.
  • Red Hat: Voorlopige score van 8.1 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H). Het verschil is de aanvalcomplexiteit: hoog in plaats van laag.

Voor operationele prioritering is een omgeving-specifieke analyse nuttiger dan één universele score:

OmgevingsfactorWaarom urgentie verandertActie voor verdediger
Publiek bereikbare TCP-serviceNiet-vertrouwde gebruikers kunnen handshake-paden activerenPatchen in het eerste noodvenster
MPTCP-listener ingeschakeldOnderzoek toonde remote root execution in deze configuratieOnmiddellijk patchen en MPTCP uitschakelen indien ongebruikt
Management-only host achter filteringNetwerktoegang is beperkt, maar insider-paden blijven bestaanSnel patchen via normale change control
Request-migratie of reuseport BPFUpstream beschrijft een gerelateerd shared-object padInventariseer configuratie en prioriteer getroffen listeners
Vendor markeert build als fixedCorrectie kan zijn gebackport binnen een oude basisversieVerifieer actieve build en bewaar bewijs
Niet-ondersteunde kernelGeen betrouwbare update of vendor-analyse beschikbaarUpgrade naar ondersteunde kernel of isoleer host

Het onderzoek van Anthropic naar MPTCP

Het onderzoek van Anthropic (27 oktober) beschrijft een remote, zero-click exploit tegen een server met een Multipath TCP-listener. De exploit verliep in twee fasen:

  1. Het verkrijgen van een kernel-pointer en het omzeilen van KASLR (Kernel Address Space Layout Randomization).
  2. Het omzetten van geheugencorruptie in control-flow hijacking om commando's als root uit te voeren.

De PoC nam ongeveer 48 minuten in beslag om een pointer te onthullen en vijf minuten voor command execution. Omdat een mislukte poging de host niet noodzakelijkerwijs laat crashen, zijn herhaalde pogingen mogelijk.

Dit bewijst dat de kwetsbaarheid verder gaat dan een Denial of Service (DoS), maar het is geen universeel recept. De exploitbaarheid hangt af van netwerklatentie, CPU-aantal, load, allocator-gedrag en hardening.

Getroffen versies en vendor-backports

Omdat de fout over veel onderhouden branches verspreid is, zijn er verschillende fixes.

Upstream stable fixes (onder andere):

  • 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 en de 7.3 development line.

Vendor-specifieke informatie:

  • Debian: De security tracker markeert Bookworm (6.1.190-1) en Trixie (6.12.113-1) als gefixt.
  • Ubuntu: Gebruikt verschillende kernel-flavors (generic, AWS, Azure, GCP, etc.). De status per flavor moet apart worden gecontroleerd. Op 29 oktober 2026 waren versies 26.10, 26.04 LTS, 24.04 LTS en 22.04 LTS nog kwetsbaar (werk in uitvoering).
  • Red Hat: RHEL 8, 9, 10 en OpenShift 4 RHEL CoreOS 8/9 zijn getroffen. RHEL 6 en 7 zijn niet getroffen.

Containers: Containers delen de host-kernel. Het updaten van een applicatie-image lost het probleem niet op; de host-node moet worden gepatcht en herstart.

Inventarisatie en Validatie

Blootstelling inventariseren

Begin met systemen die TCP direct termineren op Linux: reverse proxies, webservers, API-gateways, ingress-nodes, VPN-concentrators, loadbalancers, etc.

Controleer MPTCP-status:

  • Gebruik ip mptcp endpoint show en ip mptcp limits show.
  • Controleer sysctl net.mptcp.enabled.
  • Inspecteer request-migratie met sysctl net.ipv4.tcpmigratereq.

Veilige validatie (zonder exploit-verkeer)

Gebruik de volgende commando's om lokale feiten te verzamelen:

# Basis systeeminfo
uname -a
uname -r
cat /etc/os-release

# Debian en Ubuntu pakketbewijs
dpkg-query -W 'linux-image*' 2>/dev/null | sed -n '1,40p'

# RHEL-familie pakketbewijs
rpm -q kernel kernel-core 2>/dev/null

# Luisterende TCP-sockets
ss -lntp

# MPTCP status (indien ondersteund)
sysctl net.mptcp.enabled 2>/dev/null
ip mptcp endpoint show 2>/dev/null
ip mptcp limits show 2>/dev/null

# Request migratie instelling
sysctl net.ipv4.tcp_migrate_req 2>/dev/null

Educatieve Proof of Concept (Simulatie)

Dit Python-voorbeeld modelleert de levensduur-invariant, niet de trigger van de kwetsbaarheid. Het stuurt geen pakketten en heeft geen privileges nodig.

def simulate(deferred):
    readers = 1                   # Een bestaande lezer houdt het object vast
    allocated = True
    free_requested = True

    if not deferred:
        allocated = False         # Modelleert onmiddellijke terugvordering (fout)
    elif readers == 0:
        allocated = False         # Uitgestelde pad moet wachten

    stale_read_possible = not allocated
    readers -= 1                  # Bestaande lezer verlaat het object

    if deferred and free_requested and readers == 0:
        allocated = False

    return stale_read_possible, allocated

# Test: direct vrijgeven leidt tot een mogelijke stale read
assert simulate(False) == (True, False)
# Test: uitgesteld vrijgeven (RCU) voorkomt een stale read
assert simulate(True) == (False, False)

print("Immediate reclaim: reader can outlive allocation")
print("Deferred reclaim: existing reader finishes before free")

Detectie en Incident Response

Detectie moet een combinatie zijn van kernel-telemetrie en netwerkgedrag.

  • Kernel-logs: Zoek naar crashes met stacks nabij ipoptionsbuild(), ipbuildandsendpkt(), TCP SYN-ACK constructie of socket destructie.
  • KASAN: In testomgevingen zijn KASAN-rapporten over use-after-free met inetopt of ireqopt zeer relevant.
  • Netwerk: Let op clients die herhaaldelijk verbindingen proberen te maken met ongebruikelijke optiecombinaties tegen een MPTCP-listener.

Bij vermoeden van exploitatie: isoleer de host, capture vluchtige status en roteer credentials. Herstel het systeem vanuit een vertrouwde image in plaats van enkel een pakket-update uit te voeren.

Patch- en Mitigatiestrategie

Voorkeursoplossing: Een vendor-kernel met de RCU-fix en een reboot.

Tijdelijke mitigaties (indien reboot onmogelijk is):

  1. Schakel MPTCP uit als dit niet wordt gebruikt.
  2. Beperk inkomend TCP-verkeer tot noodzakelijke bronnen en poorten.
  3. Verplaats management-services achter geauthenticeerde gateways.
  4. Pas rate-limiting of SYN-proxying toe op upstream-apparaten.

Let op: Het uitschakelen van MPTCP vermindert het risico van de publieke research-chain, maar corrigeert de onderliggende stale pointer niet.

Verificatie van de oplossing

Een succesvolle update is niet hetzelfde als een herstelde host. Verificatie vindt plaats na de reboot:

  1. Bevestig de actieve kernel met uname -r en map deze naar het vaste pakket van de leverancier.
  2. Controleer of de bootloader de juiste image heeft geselecteerd.
  3. Test de service-gezondheid vanaf beide kanten van de trust-boundary.
  4. Update ook machine-images, launch templates en recovery media om te voorkomen dat kwetsbare nodes opnieuw worden aangemaakt.

Veelgemaakte fouten bij assessments

  1. Linux als één product zien: De kernel wordt geleverd via verschillende distributies; elk heeft eigen backports.
  2. CVSS-score gelijkstellen aan prevalentie: Een score van 9.8 beschrijft de technische ernst, niet hoeveel servers daadwerkelijk worden aangevallen.
  3. Anthropic-resultaat als universeel zien: De PoC werkte tegen MPTCP; dit betekent niet dat elke TCP-listener direct op dezelfde manier exploiteerbaar is.
  4. IPv6 als universeel veilig verklaren: Hoewel de hoofd-bug IPv4-specifiek is, is er een apart IPv6-migratieprobleem met CALIPSO.
  5. Alleen applicatie-containers scannen: Containers delen de host-kernel; de node moet worden gepatcht.
  6. Exploit-code gebruiken als productietest: Dit kan de machine crashen of compromitteren.
  7. Ticket sluiten na installatie zonder reboot: De oude kernel blijft actief tot na de reboot.

FAQ

Staat CVE-2026-98432 remote root toegang toe op elke Linux-server? Nee. De bug is netwerk-bereikbaar, maar exploitatie hangt af van kernel-build, configuratie, architectuur en race-betrouwbaarheid. Elke bereikbare host moet echter gepatcht worden.

Is CVE-2026-98432 gefixt in AlmaLinux? Dit is onbekend in deze review. Controleer de officiële AlmaLinux errata voor uw specifieke release.

Is IPv6 getroffen? De hoofd-bug in tcpv4synrecvsock() is IPv4-specifiek. Er is echter een apart concern voor IPv6-migratie bij gebruik van CALIPSO.

Lost het uitschakelen van MPTCP de kwetsbaarheid op? Nee, het vermindert enkel de onmiddellijke blootstelling aan de specifieke aanvalsmethode uit het onderzoek. De onderliggende fout blijft bestaan.

Laatste defensieve prioriteiten

Prioriteer exposed MPTCP-listeners en internet-facing Linux TCP-terminatiepunten. Gebruik vendor-pakketgegevens in plaats van generieke versie-matching. Pas de gecorrigeerde kernel toe, herstart, valideer de operatie en update alle templates.

De belangrijkste technische les is dat RCU-bescherming een contract is tussen lezers en terugvorderaars. Een lezer-lock kan een object niet beschermen dat door een schrijver direct aan de allocator wordt teruggegeven. De patch herstelt dit contract door te wachten op lezers voordat gedeelde IP-opties worden vrijgegeven.