CVE-2026-53360: KVM SEV-SNP PSC heap out-of-bounds

Prova de conceito para uma leitura e escrita fora dos limites do heap no tratamento da alteração de estado de página (PSC) do SEV-SNP do KVM. Um convidado SEV-SNP malicioso faz com que o kernel anfitrião percorra um array de entradas PSC além do final da sua alocação slab. Isso vaza o layout dos objetos kmalloc-cg-32 vizinhos e escreve neles um valor pequeno controlado, e o convidado pode repetir o processo quantas vezes quiser.

Artigo completo: https://cyberstan.co.uk/sev-snp-oob/

Impacto

Qualquer convidado SEV-SNP pode corromper o heap do kernel anfitrião e ler informações sobre seu layout enviando uma solicitação PSC malformada. Esta é a direção convidado para anfitrião: o SEV-SNP foi criado para proteger o convidado de um anfitrião não confiável, mas o anfitrião ainda precisa se defender contra um convidado malicioso, e este tratador não o faz.

Requisitos

Isso requer hardware SEV-SNP real. Não pode ser reproduzido em Intel, e virtualização aninhada não fornecerá um convidado SNP.

Hardware:

• Um chip de servidor AMD EPYC com SEV-SNP: Milan (7003) ou mais novo, ou seja, Genoa (9004), Bergamo, Siena ou Turin. SEV-SNP é silício exclusivo da EPYC. Não está disponível em Ryzen ou Threadripper, e não há equivalente Intel aqui (a Intel usa TDX).
• Metal nu. Uma instância de nuvem bare-metal também funciona (Vultr, AWS *.metal, Hetzner AX e similares).
• Na BIOS, habilite SEV, SEV-ES, SEV-SNP, SME, IOMMU e SVM. Nuvens bare-metal gerenciadas geralmente já vêm com essas opções ativadas.

Kernel do host:

• Construa-o com KASAN para que os acessos fora dos limites sejam relatados. Sem KASAN, o bug ainda corrompe a memória do host, apenas não é exibido. Testado em 6.11.11.
  root@kitploit:~

  CONFIG_KASAN=y
  CONFIG_KASAN_GENERIC=y
  CONFIG_KVM=y
  CONFIG_KVM_AMD=y
  CONFIG_KVM_AMD_SEV=y
  CONFIG_CRYPTO_DEV_SP_PSP=y
  

• Inicialize com SNP ativado e KASAN no modo multi-shot para que cada ocorrência seja registrada:
  root@kitploit:~

  kvm_amd.sev=1 kvm_amd.sev_es=1 kvm_amd.sev_snp=1 kasan_multi_shot
  

• Confirme que o host está pronto:
  root@kitploit:~

  cat /sys/module/kvm_amd/parameters/sev_snp     # Y
  ls /dev/sev                                     # /dev/sev
  

Userspace do host:

• Um QEMU com capacidade SNP. O QEMU padrão não oferece suporte a SNP, então construa o fork da AMD:
  root@kitploit:~

  git clone https://github.com/AMDESE/qemu.git
  cd qemu && git checkout snp-latest
  mkdir build && cd build
  ../configure --target-list=x86_64-softmmu && make -j$(nproc)
  

• Firmware SNP OVMF de https://github.com/AMDESE/AMDSEV/releases.

Convidado:

• Qualquer convidado Linux que inicialize sob SNP, com build-essential e linux-headers-$(uname -r) instalados para que você possa construir o módulo dentro dele.

O bug

Convidados SEV-SNP se comunicam com o host através do GHCB, uma página compartilhada de 4 KB. Uma solicitação PSC define SW_EXITCODE como SVM_VMGEXIT_PSC (0x80000010), aponta SW_SCRATCH para um descritor e coloca o comprimento do descritor em SW_EXITINFO2.

O descritor é um struct psc_buffer: um cabeçalho de 8 bytes seguido por um array de entradas de 8 bytes. Não há um campo de contagem explícito. O host processa as entradas de hdr->cur_entry até hdr->end_entry, ambos controlados pelo convidado.

struct psc_hdr {
        u16 cur_entry;
        u16 end_entry;
        u32 reserved;
} __packed;                     /* 8 bytes */

struct psc_entry {
        u64 cur_page    : 12;
        u64 gfn         : 40;
        u64 operation   :  4;
        u64 pagesize    :  1;
        u64 reserved    :  7;
} __packed;                     /* 8 bytes */

Um convidado GHCB v2+ deve manter sua área de rascunho dentro do Buffer Compartilhado de 2032 bytes do GHCB, para que o host possa reutilizar seu mapeamento existente. (2032 - 8) / 8 = 253 entradas cabem ali, que é de onde vem o máximo do protocolo VMGEXIT_PSC_MAX_COUNT (253). Esse número só faz sentido quando o buffer é realmente o Buffer Compartilhado.

Se o convidado apontar a área de rascunho para fora do GHCB, o host não pode usar seu mapeamento, então setup_vmgexit_scratch() aloca um buffer separado do tamanho solicitado pelo convidado. SNP nunca deve seguir esse caminho, mas nada o impede:

scratch_va = kvzalloc(len, GFP_KERNEL_ACCOUNT);   /* len == exit_info_2, controlado pelo convidado */

len vem diretamente do convidado, e GFP_KERNEL_ACCOUNT coloca a alocação nos caches kmalloc-cg-N contabilizados por cgroup. Solicite exit_info_2 = 24 e você obtém uma alocação de 24 bytes no slot de 32 bytes kmalloc-cg-32: espaço para o cabeçalho mais duas entradas. Tudo além de entries[1] é memória de outro objeto.

Então snp_begin_psc() verifica a contagem de entradas em relação à constante do protocolo, não em relação ao buffer que realmente alocou:

idx_end = hdr->end_entry;

if (idx_end >= VMGEXIT_PSC_MAX_COUNT) {   /* verifica 253, NÃO o tamanho do buffer */
        snp_complete_psc(svm, ...);
        return 1;
}

for (idx = idx_start; idx <= idx_end; idx++) {
        entry_start = entries[idx];       /* OOB quando idx >= 2 */
        ...
}

Com um buffer de 24 bytes existem apenas duas entradas, mas a verificação permite end_entry até 252. Defina-o como 252 e o loop percorre cerca de 2 KB após a alocação, atravessando objetos slab vizinhos.

Primitivas

Cada passo além do fim reinterpreta os próximos 8 bytes da memória slab como um psc_entry e o processa através do código PSC. Isso fornece três coisas:

1. Oráculo de leitura. O host lê o qword adjacente apenas para decodificá-lo, extraindo entry.gfn e entry.operation da memória que o buffer nunca possuiu. Esta é a leitura slab-out-of-bounds que o KASAN captura.
2. Escrita restrita. Se a entrada decodificada parecer válida e for despachada como KVM_HC_MAP_GPA_RANGE, o código de conclusão escreve de volta no mesmo slot OOB: entries[idx].cur_page = entry.pagesize ? 512 : 1. Um de dois valores pequenos nos 12 bits baixos de uma palavra escolhida pelo convidado, repetível.
3. Oráculo de falha. Se a entrada não validar, a resposta em SW_EXITINFO2 relata o índice em que parou. Incrementar end_entry um de cada vez vaza, slot por slot, se a memória adjacente decodificou como um no-op ou como algo que falhou, o que é suficiente para encontrar limites de objetos e distinguir zero de não zero.

Cada VMGEXIT realoca o buffer de rascunho, então solicitações repetidas caem em diferentes slots da freelist e permitem que o convidado percorra vizinhos em vez de ficar preso em um. Juntos, isso produz divulgação do layout do heap, a escrita restrita acima e use-after-free entre solicitações.

O que o PoC faz

trigger.c é um módulo de kernel do convidado. Carregue-o dentro de um convidado SEV-SNP e ele conduz quatro estágios contra o host a partir de um único insmod:

• Estágio 1 testa 48 entradas fora dos limites uma de cada vez e constrói um mapa do heap do host (memória vizinha zero vs não zero).
• Estágio 2 prova que a escrita OOB persiste entre VMGEXITs escrevendo cur_page em um vizinho zero e confirmando que uma solicitação posterior o ignora.
• Estágio 3 dispara uma solicitação com end_entry=200 e mede até onde a leitura OOB alcança antes de atingir dados não zero.
• Estágio 4 dispara 200 solicitações com entries[3..10] fora dos limites, cada uma das quais aciona um relatório KASAN no host.

O módulo aloca uma página, marca-a como descriptografada com set_memory_decrypted(), a usa como área de rascunho e constrói manualmente a solicitação PSC do GHCB. Ele sai com -EAGAIN para não permanecer carregado.

Construção e execução

1. Iniciar um convidado SNP

Ajuste os caminhos do OVMF e do disco para sua configuração:

qemu-system-x86_64 \
    -enable-kvm -cpu EPYC-v4 \
    -machine q35,confidential-guest-support=sev0,memory-backend=ram1 \
    -object memory-backend-memfd,id=ram1,size=4G \
    -object sev-snp-guest,id=sev0,cbitpos=51,reduced-phys-bits=1,policy=0x30000 \
    -smp 4 -m 4G \
    -bios OVMF_SNP.fd \
    -drive file=guest.qcow2,format=qcow2,if=virtio \
    -netdev user,id=net0,hostfwd=tcp::2222-:22 \
    -device virtio-net-pci,netdev=net0 \
    -nographic

2. Construir e carregar no convidado

Copie trigger.c e Makefile para o convidado, então:

make
insmod trigger.ko

O módulo verifica primeiro o SEV-SNP via CPUID e se recusa a executar em qualquer outro lugar. Ele executa seus quatro estágios e se descarrega (init retorna -EAGAIN, então nunca permanece residente).

3. Observar o anfitrião

No anfitrião:

dmesg | grep -E "KASAN|BUG|snp_begin_psc"

Saída esperada:

BUG: KASAN: slab-out-of-bounds in snp_begin_psc+0x126/0x890
Read of size 8 at addr ffff888219ffb5e0 by task qemu-system-x86/2199

BUG: KASAN: slab-out-of-bounds in snp_begin_psc+0x468/0x890
Write of size 8 at addr ffff888351566648 by task qemu-system-x86/2199

The buggy address belongs to the object at ffff888XXXXXXXXX
 which belongs to the cache kmalloc-cg-32 of size 32

Um único insmod produziu 73 relatórios KASAN no host de teste (62 slab-out-of-bounds, 7 slab-use-after-free, 4 use-after-free), todos contra kmalloc-cg-32. Host de teste: AMD EPYC 7443P, Ubuntu 24.04.4, kernel 6.11.11 com KASAN, convidado sob AMDESE QEMU (snp-latest).

A correção

A correção upstream rejeita qualquer área de rascunho fora do GHCB para GHCB v2 e posteriores em setup_vmgexit_scratch(), o que fixa o buffer a um tamanho fixo e conhecido, de modo que o loop nunca possa ultrapassar o final:

  } else {
+         /* GHCB v2 requires the scratch area to be within the GHCB. */
+         if (to_kvm_sev_info(svm->vcpu.kvm)->ghcb_version >= 2)
+                 goto e_scratch;
+
          /*
           * The guest memory must be read into a kernel buffer, so
           * limit the size

Essas quatro linhas são db3f219. Elas chegaram como parte de uma série maior que também limita a contagem de entradas em relação ao tamanho real do buffer e relê o descritor uma vez através de READ_ONCE(), o que fecha uma variante de deslocamento para dentro do buffer e uma condição de corrida TOCTOU no mesmo tratador.

Arquivos

Solução de problemas

• not an SEV-SNP guest: QEMU não foi iniciado com sev-snp-guest, ou o SNP do host está desligado.
• QEMU SEV-SNP not supported: verifique /sys/module/kvm_amd/parameters/sev_snp, as configurações da BIOS e os parâmetros de boot.
• QEMU LAUNCH_START failed: o PSP não foi inicializado. Verifique dmesg | grep psp e CONFIG_CRYPTO_DEV_SP_PSP=y.
• Nenhuma saída KASAN: verifique CONFIG_KASAN=y e kasan_multi_shot na linha de comando do host.

Aviso

Isso corrompe a memória do heap do kernel do host, aciona o KASAN e pode travar o host. Execute-o apenas em um host de teste descartável que você controla, dentro de uma VM que você possui. Não execute em infraestrutura compartilhada ou de produção.

Referências

• Artigo: https://cyberstan.co.uk/sev-snp-oob/
• CVE-2026-53360 (acompanhe o commit db3f219 no linux-cve-announce)
• Correção: db3f219, autor Mike Roth, revisado por Tom Lendacky, submetido por Paolo Bonzini
• Introduzido: 9b54e248d264; correção marcada Fixes: 4af663c
• Especificação GHCB, seção 2.1 (SW_SCRATCH deve estar dentro do buffer compartilhado do GHCB)

Licença

trigger.c é GPL-2.0, correspondendo ao seu MODULE_LICENSE. Veja LICENSE.