abraxaslabs.tech  ·  github.com/abraxas  ·  @abraxas_null  ·  [email protected]  ·  qemu-xhci-complete-uaf

qemu-xhci-complete-uaf

QEMU v11.1.2 (4fc49f46dc95d4a27de2509e7fceb2931e91faeb) - qemu-xhci

Classe: UAF (use-after-free de heap). Alcance: Local (guest).

xhci_complete é o resquício da CVE-2026-17588. O patch da 11.1.2 protege os dois timers do xHCI. Ele não protege o caminho de conclusão assíncrona do USB. Um guest que aponta o event ring para a BAR do doorbell ainda consegue que um TRB de 16 bytes seja gravado por DMA no doorbell 0 a partir de xhci_complete, com o mem_reentrancy_guard do TYPE_XHCI já liberado. Essa escrita executa xhci_process_commands. Um CR_DISABLE_SLOT preparado libera o XHCITransfer ativo enquanto xhci_complete ainda o mantém.

O q35 inclui o qemu-xhci. O parceiro bulk neste laboratório é o usb-uas. O mesmo callback de conclusão é alcançável a partir de usb-storage, usb-redir e usb-host.

Um kernel guest no qemu-xhci mais um dispositivo bulk assíncrono pode causar UAF no heap do processo QEMU.

ID	ainda sem CVE
CWE	CWE-416
CVSS	Alto: 8.2 CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H
Produto	QEMU
Afetado	v11.1.2 (4fc49f46)
Autenticação	kernel guest no qemu-xhci (padrão do q35) mais bulk USB_RET_ASYNC
Licença	GNU Affero GPL v3.0
Laboratório	127.0.0.1:18700 somente qtest

O que um atacante pode fazer

Quem: kernel guest não confiável (ou par de passthrough USB). Guest para host. Heap do espaço de usuário do QEMU.

Integridade (comprovada em laboratório)

Método	Destino	Privilégio
ERST / ERDP do guest na BAR do doorbell, depois conclusão assíncrona do UAS	xhci_complete hw/usb/hcd-xhci.c:3282-3295 -> DMA de xhci_write_event	heap-use-after-free no ASan do XHCITransfer enquanto a conclusão externa ainda o mantém. CR_DISABLE_SLOT obtido a partir da reentrada no doorbell.
Mesmo caminho, xhci_ep_nuke_xfers / xhci_ep_free_xfer	g_free(xfer)	Liberação da transferência ativa e do contexto do endpoint. Double-free se a conclusão liberar novamente.

Disponibilidade (comprovada em laboratório)

Abort do processo QEMU sob ASan. Sem ASan, trata-se de um UAF de heap ativo no processo do hypervisor: crash de guest para host, e reutilização inferida do XHCITransfer liberado.

Reconhecimento

Nada além de enumerar o qemu-xhci. O padrão do q35 já o inclui.

Superfície adjacente que permanece fechada

• Caminho de timer da CVE-2026-17588: xhci_mfwrap_timer e xhci_ep_kick_timer definem xhci->parent.mem_reentrancy_guard. Fechado neste pin.
• Conclusão assíncrona do EHCI: marca FINISHED e agenda um BH protegido. Não grava no event ring a partir do callback de conclusão do USB.
• UAF do objeto UAS (classe CVE-2021-3713): o BH de status é protegido no DeviceState do UAS. O resquício é o objeto xHCI via DMA do event ring, não um n-day de 2021 do objeto UAS.
• Retry de NAK do HID: esse é o kick timer, agora protegido.
• Asserts de root no guest e alocação RNDIS sem limite: hardening, não esta classe.

O laboratório não demonstra controle de RIP nem um shell de guest para host. A classe é UAF de heap do processo QEMU.

Como eu encontrei

Fixe no v11.1.2 porque essa é a GA atual e a tag que fechou a CVE-2026-17588. Examinei hw/usb/hcd-xhci.c e perguntei quais escritores do event ring o patch deixou passar.

Os timers adquirem o guard do TYPE_XHCI. xhci_complete não. O EHCI já adiou essa classe para um BH em 2021. O xHCI ainda grava por DMA a partir do callback de conclusão do USB.

Erros de percurso: considerar o status BH do UAS suficiente (ele protege o UAS, não o xHCI); esperar por HID NAK (timer, já corrigido); querer um kernel guest real em vez de qtest doorbell + usb-uas.

Lab

cd lab
./run.sh

Tem como alvo apenas 127.0.0.1:18700 (qtest) e 127.0.0.1:18701 (QMP). O Pin é clonado de github.com/qemu/QEMU tag v11.1.2 / 4fc49f46. Build com ASan. Loopback. Apenas testemunha.

SUCCESS qemu-xhci-complete-uaf how=ERROR: AddressSanitizer: heap-use-after-free erst=doorbell async=1 success=1 disable-slot-fetch=1 QEMU-XHCI-COMPLETE-UAF-WITNESS

Replay: python3 qemu-xhci-complete-uaf-Abraxas-Labs.py.

A correção

Acione xhci->parent.mem_reentrancy_guard durante todo o xhci_complete, da mesma forma que os dois timers já fazem. Ou adie xhci_try_complete_packet / xhci_kick_epctx para um BH protegido por TYPE_XHCI, à semelhança do EHCI. De qualquer forma, a escrita DMA no event ring não deve ser executada com o guard desativado.

Referências

• github.com/qemu/QEMU tag v11.1.2 commit 4fc49f46dc95d4a27de2509e7fceb2931e91faeb
• xhci_complete
• Próximo corrigido (não este caminho): CVE-2026-17588 reentrância de timer do xHCI
• Mesmo pin: qemu-nvme-sgl-bar · qemu-colo-l4-oob
• Série: QEMU 11.1.2 leftovers
• CWE-416

Licença

GNU Affero GPL v3.0. Consulte LICENSE. Apenas laboratório de loopback. Sem garantias.