Hva er ITScape?

ITScape er en kappløpstilstand i KVM sin innebygde virtuelle Generic Interrupt Controllers Interrupt Translation Service (vGIC-ITS). Denne tjenesten håndterer LPI-oversettelse for virtualiserte ARM64-gjester. Når en oppføring i oversettelsesbufferen må ugyldiggjøres, går kjernen gjennom oppføringene og frigir referansene deres. Svakheten ligger i at funksjonen som ugyldiggjør (vgic_its_invalidate_cache()), reduserer referansetelleren for hver eneste oppføring iteratoren returnerer – også oppføringer som en annen, samtidig operasjon allerede har fjernet fra bufferen .

Denne doble referansefrigjøringen skaper et klassisk use-after-free (UAF)-problem: to ulike kjøringsstier kan ende opp med å jobbe på minne som allerede er frigitt, noe som gir angriperen et vindu til å manipulere minnet og til slutt kapre kontrollflyten på vertskjernenivå .

Feilen ligger spesifikt i vgic_its_invalidate_cache(), som går gjennom ITS-oversettelsesbufferen med xa_for_each() og kaller vgic_put_irq() på den iterasjonspekeren, i stedet for på verdien som trygt returneres av xa_erase(). Flere kontekster kan gå inn i denne funksjonen under forskjellige låser, så kappløpet kan utløses direkte fra en gjest ved å kombinere ITS-kommandohåndtering, et GITS_CTLR-skriv, og å slette EnableLPIs i en redistributør .

Derfor er dette viktig: Den første KVM/arm64 gjest-til-vert-flukten

Gjest-til-vert-flukter er sjeldne, men de utgjør den farligste typen hypervisorfeil fordi de river ned isolasjonsbarrieren som nettskyen er bygget på. Tidligere offentlige KVM-flukter var rettet mot x86, ofte via QEMU- eller AMD-spesifikk kode . ITScape er den første fungerende utnyttelsen som viser et utbrudd fra en uprivilegert ARM64-gjest gjennom selve den innebygde KVM-koden – uten behov for feil i emulatorer i brukerområdet .

For skyleverandører som kjører AWS Graviton, Ampere Altra eller en hvilken som helst annen KVM/ARM64-vert med flerbrukerbelastninger, kan en angriper i en gjest:

• Lese og skrive vilkårlig minne i vertskjernen
• Oppnå rettighetsnivå 0 (ring 0) og kjøre kode på verten
• Bevege seg sideveis til andre virtuelle maskiner, containere eller vertens nettverk

De fleste sikkerhetsteam har vurdert sårbarheten til over CVSS 9.0, noe som indikerer kritisk alvorlighetsgrad .

Rotårsaken i detalj

Den sårbare koden ligger i ugyldiggjøringsstien til LPI-oversettelsesbufferen. Når kjernen trenger å tømme buffer-oppføringer, itererer den gjennom XArray-datastrukturen med xa_for_each() og kaller vgic_put_irq() for å frigi referansetelleren på hver oppføring. Problemet er at xa_for_each() returnerer oppføringer som kan ha blitt slettet av en samtidig operasjon, som en DISCARD ITS-kommando fra en annen vCPU. Ugyldiggjøringsløkken reduserer likevel referansen på den allerede fjernede oppføringen, noe som forårsaker en dobbel put og til slutt et bruk-etter-frigjøringsproblem .

En tidligere sårbarhet i den samme koden, CVE-2024-26598, hadde delvis adressert et UAF-problem i treff-stien til LPI-oversettelsesbufferen ved å øke referansetelleren inne i vgic_its_check_cache() før den slapp låsen. Denne fiksen dekket imidlertid ikke ugyldiggjøringsstien, og lot kappløpet være utnyttbart via en annen triggesekvens .

Fiksen

Den offisielle fiksen endrer vgic_its_invalidate_cache() slik at vgic_put_irq() kun kalles på verdien som returneres av xa_erase(), og ikke på hver oppføring iteratoren berører. Selve commit-meldingen lyder: "KVM: arm64: vgic-its: Drop the translation cache reference only for the erased entry" .

Siden xa_erase() atomisk fjerner og returnerer den gamle oppføringen – eller returnerer NULL hvis oppføringen allerede var borte – sikrer fiksen at referansetelleren kun reduseres én gang, noe som eliminerer muligheten for dobbel frigjøring. Oppdateringen ble inkludert i oppstrømskjernen tidlig i juni 2026 og raskt dratt inn i 6.x-stabilserien rundt 8.–10. juni 2026 . Store distribusjoner som Red Hat, SUSE og Debian har utstedt bakoverportede fikser for sine støttede kjernegrener .

Berørte versjoner

• Introdusert: Slutten av april 2024, da LPI-oversettelsesbufferen først ble lagt til KVM/arm64
• Sårbart vindu: Oppstrømskjerner bygget fra omtrent april 2024 til tidlig juni 2026
• Fikset: Oppstrømsfiks inkludert tidlig i juni 2026; inkludert i de nyeste 6.x-stabile kjernene og distribusjoners bakoverporteringer

Konseptutnyttelse (PoC)

Hyunwoo Kim publiserte en fungerende angrepskode på GitHub rundt 9.–10. juni 2026. Repositoryet inneholder full kildekode, steg-for-steg-instruksjoner for reproduksjon og en teknisk beskrivelse av utnyttelsesteknikken . Utnyttelsen trigger kappløpet ved å koordinere vCPU-tråder som samtidig utfører DISCARD-kommandoer og LPI-oversettelsesbuffer-oppslag for å presist lande bruk-etter-frigjøring og oppnå vertskodeeksekvering.

At en pålitelig angrepskode er offentlig tilgjengelig, betyr at ferdige angrepsverktøy og reelle trusselaktører kan våpenliggjøre sårbarheten med minimal innsats. Dette forkorter tiden mellom offentliggjøring og aktive angrep dramatisk.

Tiltak for ARM64-skyoperatører – haster!

Hvis du drifter flerbruker-ARM64 KVM-infrastruktur – enten det er AWS Graviton, Ampere Altra eller lignende plattformer – må du behandle dette som en umiddelbar kriseoppdatering.

1. Oppdater vertskjernen nå. Installer den nyeste stabile kjernen med fiksen fra tidlig juni 2026, eller distribusjonens bakoverportede pakke .
2. Deaktiver den innebygde vGIC-ITS for upålitelige gjester omgående dersom du ikke kan oppdatere med én gang. Med QEMU kan dette gjøres ved å tvinge GICv3 ITS-emulering til brukerområdet, eller ved å ikke eksponere GICv3 ITS-funksjonalitet for upålitelige leietakere .
3. Ikke stol på sikkerhetstiltak inne i gjesten. Dette er en feil på hypervisornivå; det finnes ingen løsning på innsiden av den virtuelle maskinen .
4. Kartlegg hele maskinparken for sårbare kjerner. Enhver ARM64 KVM-vert som kjører en kjerne bygget mellom april 2024 og tidlig juni 2026 med vGIC-ITS aktivert, er i risikosonen .
5. Overvåk for tegn på utnyttelsesforsøk. Med offentlig tilgjengelig angrepskode er det svært sannsynlig at aktiv skanning og kompromitteringsforsøk allerede pågår .

Hva er ITScape?

ITScape er en kappløpstilstand i KVM sin innebygde virtuelle Generic Interrupt Controllers Interrupt Translation Service (vGIC-ITS). Denne tjenesten håndterer LPI-oversettelse for virtualiserte ARM64-gjester. Når en oppføring i oversettelsesbufferen må ugyldiggjøres, går kjernen gjennom oppføringene og frigir referansene deres. Svakheten ligger i at funksjonen som ugyldiggjør (vgic_its_invalidate_cache()), reduserer referansetelleren for hver eneste oppføring iteratoren returnerer – også oppføringer som en annen, samtidig operasjon allerede har fjernet fra bufferen .

Denne doble referansefrigjøringen skaper et klassisk use-after-free (UAF)-problem: to ulike kjøringsstier kan ende opp med å jobbe på minne som allerede er frigitt, noe som gir angriperen et vindu til å manipulere minnet og til slutt kapre kontrollflyten på vertskjernenivå .

Feilen ligger spesifikt i vgic_its_invalidate_cache(), som går gjennom ITS-oversettelsesbufferen med xa_for_each() og kaller vgic_put_irq() på den iterasjonspekeren, i stedet for på verdien som trygt returneres av xa_erase(). Flere kontekster kan gå inn i denne funksjonen under forskjellige låser, så kappløpet kan utløses direkte fra en gjest ved å kombinere ITS-kommandohåndtering, et GITS_CTLR-skriv, og å slette EnableLPIs i en redistributør .

Derfor er dette viktig: Den første KVM/arm64 gjest-til-vert-flukten

Gjest-til-vert-flukter er sjeldne, men de utgjør den farligste typen hypervisorfeil fordi de river ned isolasjonsbarrieren som nettskyen er bygget på. Tidligere offentlige KVM-flukter var rettet mot x86, ofte via QEMU- eller AMD-spesifikk kode . ITScape er den første fungerende utnyttelsen som viser et utbrudd fra en uprivilegert ARM64-gjest gjennom selve den innebygde KVM-koden – uten behov for feil i emulatorer i brukerområdet .

For skyleverandører som kjører AWS Graviton, Ampere Altra eller en hvilken som helst annen KVM/ARM64-vert med flerbrukerbelastninger, kan en angriper i en gjest:

• Lese og skrive vilkårlig minne i vertskjernen
• Oppnå rettighetsnivå 0 (ring 0) og kjøre kode på verten
• Bevege seg sideveis til andre virtuelle maskiner, containere eller vertens nettverk

De fleste sikkerhetsteam har vurdert sårbarheten til over CVSS 9.0, noe som indikerer kritisk alvorlighetsgrad .

Rotårsaken i detalj

Den sårbare koden ligger i ugyldiggjøringsstien til LPI-oversettelsesbufferen. Når kjernen trenger å tømme buffer-oppføringer, itererer den gjennom XArray-datastrukturen med xa_for_each() og kaller vgic_put_irq() for å frigi referansetelleren på hver oppføring. Problemet er at xa_for_each() returnerer oppføringer som kan ha blitt slettet av en samtidig operasjon, som en DISCARD ITS-kommando fra en annen vCPU. Ugyldiggjøringsløkken reduserer likevel referansen på den allerede fjernede oppføringen, noe som forårsaker en dobbel put og til slutt et bruk-etter-frigjøringsproblem .

En tidligere sårbarhet i den samme koden, CVE-2024-26598, hadde delvis adressert et UAF-problem i treff-stien til LPI-oversettelsesbufferen ved å øke referansetelleren inne i vgic_its_check_cache() før den slapp låsen. Denne fiksen dekket imidlertid ikke ugyldiggjøringsstien, og lot kappløpet være utnyttbart via en annen triggesekvens .

Fiksen

Den offisielle fiksen endrer vgic_its_invalidate_cache() slik at vgic_put_irq() kun kalles på verdien som returneres av xa_erase(), og ikke på hver oppføring iteratoren berører. Selve commit-meldingen lyder: "KVM: arm64: vgic-its: Drop the translation cache reference only for the erased entry" .

Siden xa_erase() atomisk fjerner og returnerer den gamle oppføringen – eller returnerer NULL hvis oppføringen allerede var borte – sikrer fiksen at referansetelleren kun reduseres én gang, noe som eliminerer muligheten for dobbel frigjøring. Oppdateringen ble inkludert i oppstrømskjernen tidlig i juni 2026 og raskt dratt inn i 6.x-stabilserien rundt 8.–10. juni 2026 . Store distribusjoner som Red Hat, SUSE og Debian har utstedt bakoverportede fikser for sine støttede kjernegrener .

Berørte versjoner

• Introdusert: Slutten av april 2024, da LPI-oversettelsesbufferen først ble lagt til KVM/arm64
• Sårbart vindu: Oppstrømskjerner bygget fra omtrent april 2024 til tidlig juni 2026
• Fikset: Oppstrømsfiks inkludert tidlig i juni 2026; inkludert i de nyeste 6.x-stabile kjernene og distribusjoners bakoverporteringer

Konseptutnyttelse (PoC)

Hyunwoo Kim publiserte en fungerende angrepskode på GitHub rundt 9.–10. juni 2026. Repositoryet inneholder full kildekode, steg-for-steg-instruksjoner for reproduksjon og en teknisk beskrivelse av utnyttelsesteknikken . Utnyttelsen trigger kappløpet ved å koordinere vCPU-tråder som samtidig utfører DISCARD-kommandoer og LPI-oversettelsesbuffer-oppslag for å presist lande bruk-etter-frigjøring og oppnå vertskodeeksekvering.

At en pålitelig angrepskode er offentlig tilgjengelig, betyr at ferdige angrepsverktøy og reelle trusselaktører kan våpenliggjøre sårbarheten med minimal innsats. Dette forkorter tiden mellom offentliggjøring og aktive angrep dramatisk.

Tiltak for ARM64-skyoperatører – haster!

Hvis du drifter flerbruker-ARM64 KVM-infrastruktur – enten det er AWS Graviton, Ampere Altra eller lignende plattformer – må du behandle dette som en umiddelbar kriseoppdatering.

1. Oppdater vertskjernen nå. Installer den nyeste stabile kjernen med fiksen fra tidlig juni 2026, eller distribusjonens bakoverportede pakke .
2. Deaktiver den innebygde vGIC-ITS for upålitelige gjester omgående dersom du ikke kan oppdatere med én gang. Med QEMU kan dette gjøres ved å tvinge GICv3 ITS-emulering til brukerområdet, eller ved å ikke eksponere GICv3 ITS-funksjonalitet for upålitelige leietakere .
3. Ikke stol på sikkerhetstiltak inne i gjesten. Dette er en feil på hypervisornivå; det finnes ingen løsning på innsiden av den virtuelle maskinen .
4. Kartlegg hele maskinparken for sårbare kjerner. Enhver ARM64 KVM-vert som kjører en kjerne bygget mellom april 2024 og tidlig juni 2026 med vGIC-ITS aktivert, er i risikosonen .
5. Overvåk for tegn på utnyttelsesforsøk. Med offentlig tilgjengelig angrepskode er det svært sannsynlig at aktiv skanning og kompromitteringsforsøk allerede pågår .