Durante anos, a engenharia de memória tratou o Rowhammer como um problema quase resolvido em hardware de ponta: bastava usar memória com correção de erro (ECC) e o risco de um simples padrão de acesso repetido corromper dados vizinhos desaparecia. Um grupo de pesquisadores da Universidade de Toronto acaba de mostrar que essa confiança era prematura — pelo menos para as placas de vídeo profissionais da NVIDIA. O ataque, batizado de GPUThor, não só reacende o Rowhammer dentro da memória GDDR6 das GPUs como transforma o próprio ECC, o mecanismo desenhado para proteger os dados, em parte do problema. O resultado documentado pelos pesquisadores foi acesso root ao computador que hospeda a placa de vídeo.
O que é Rowhammer, para quem nunca ouviu falar
Memória de computador (RAM ou VRAM) guarda informação em capacitores minúsculos organizados em fileiras dentro de um chip. Cada capacitor representa um bit: carregado é “1”, descarregado é “0”. O problema é que essas fileiras ficam extremamente próximas umas das outras, e ler ou escrever repetidamente numa fileira específica gera pequenas interferências elétricas nas fileiras vizinhas.
Rowhammer é o nome dado à técnica de “martelar” deliberadamente uma fileira de memória — acessá-la dezenas de milhares de vezes por segundo — até que essa interferência acumulada faça um bit vizinho virar de “0” para “1” ou vice-versa, sem que ninguém tenha mandado escrever ali. É um ataque de hardware, não de software: nenhuma falha de programação é explorada, apenas um efeito físico colateral do jeito como a memória moderna é fabricada, cada vez mais densa e com fileiras cada vez mais próximas.
Desde que foi demonstrado pela primeira vez em 2014, contra memória RAM comum de computadores, o Rowhammer virou uma categoria inteira de pesquisa em segurança, porque um único bit invertido no lugar certo pode ser suficiente para escalar privilégios, quebrar isolamento entre programas ou corromper dados de forma útil para um atacante.
Por que uma GPU é um alvo diferente de um computador comum
A fabricante de memória e a indústria de computadores passaram uma década criando defesas contra o Rowhammer para a RAM tradicional (DDR4, DDR5). A mais importante se chama TRR, de Target Row Refresh: um circuito dentro do próprio chip de memória que tenta identificar quais fileiras estão sendo “marteladas” com frequência anormal e força um refresh extra nelas antes que o dano aconteça.
Só que a memória usada em placas de vídeo de alto desempenho — a GDDR6, presente em GPUs profissionais e de jogos da NVIDIA — não é a mesma coisa que a DDR4 ou DDR5 do computador comum. Ela roda em frequências muito mais altas, é otimizada para banda larga de dados em vez de latência mínima, e seu controlador de memória lida com padrões de acesso completamente diferentes: uma GPU processa milhares de operações em paralelo, agrupando (“coalescendo”) acessos de memória de formas que uma CPU nunca faria. Isso significa que as suposições usadas para calibrar o TRR em memória de PC nem sempre valem para GDDR6, e um ataque desenhado especificamente para explorar essas diferenças pode literalmente enganar o mecanismo de defesa sem que ele perceba.
Foi exatamente esse caminho que a mesma equipe de Toronto já havia percorrido em 2025, com um trabalho anterior chamado GPUHammer, apresentado no USENIX Security. Naquele estudo, os pesquisadores Chris S. Lin, Joyce Qu e Gururaj Saileshwar mostraram que era possível fazer Rowhammer prático contra a GDDR6 de uma GPU NVIDIA RTX A6000. Para demonstrar o impacto prático, eles atacaram redes neurais reais — AlexNet, VGG16, ResNet50, entre outras — e conseguiram, com um único bit invertido no lugar certo (o expoente de um número em ponto flutuante de 16 bits usado para representar os pesos da rede), derrubar a acurácia de classificação de imagens de mais de 80% para menos de 0,1% em alguns modelos. Uma inteligência artificial afinada durante semanas de treinamento podia ser inutilizada por uma única inversão de bit.
A virada do GPUThor: enganar o TRR de propósito
O GPUThor, descrito em um novo artigo acadêmico que será apresentado na ACM CCS (Conference on Computer and Communications Security) em novembro de 2026, na Holanda, parte da mesma equipe — agora com um quarto pesquisador, Aditya Rajeev, somando-se a Lin, Qu e Saileshwar — e leva a ideia muito mais longe.
A descoberta central foi de engenharia reversa: analisando o comportamento real da GDDR6, os pesquisadores perceberam que o TRR das placas testadas não verifica padrões suspeitos a cada ciclo de atualização da memória (o chamado tREFI), como se supunha até então, mas sim a cada aproximadamente 72 ciclos. Ou seja, existe uma “janela” bem maior do que se pensava entre uma verificação e outra.
Com essa informação, a equipe desenhou padrões de ataque não uniformes, que dão nome ao trabalho: em vez de martelar a mesma fileira de memória do mesmo jeito o tempo todo, o ataque distribui a agressão ao longo de até seis desses ciclos, concentrando a maior parte do esforço numa fileira-alvo e reservando o último ciclo para “distrair” o TRR com acessos a fileiras-isca. O efeito prático é uma amplificação enorme: nos testes, o GPUThor produziu entre 72 mil e 377 mil inversões de bit por gigabyte de memória, dependendo do modelo de placa, contra apenas 16 inversões por gigabyte do GPUHammer original — uma eficácia de milhares de vezes maior, com o pico observado passando de 23 mil vezes na GPU mais vulnerável testada (a RTX A5000). O ataque foi validado em quatro placas profissionais da linha Ampere: RTX A4000, A4500, A5000 e A6000, todas equipadas com memória GDDR6.
Quando o ECC vira o problema, não a solução
Diante da ameaça do Rowhammer, a própria NVIDIA já recomendava, desde o GPUHammer, ativar o ECC (Error Correction Code) como mitigação. É uma lógica razoável: o ECC guarda, junto com cada bloco de dados, informação redundante que permite detectar e corrigir pequenos erros de memória automaticamente, sem intervenção humana. O tipo específico usado nessas GPUs se chama SECDED — sigla para “Single Error Correction, Double Error Detection”: ele corrige sozinho um bit invertido, e pelo menos avisa quando dois bits foram invertidos ao mesmo tempo.
O problema é que “avisar sobre dois” e “corrigir um” são os únicos casos que esse esquema sabe reconhecer com segurança. E é exatamente aí que o volume de inversões de bit gerado pelo GPUThor se torna decisivo, porque em uma massa tão grande de bits alterados aparecem, inevitavelmente, casos de dois e de três bits invertidos na mesma região de memória:
Quando exatamente dois bits são invertidos ao mesmo tempo, o ECC reconhece que algo está errado, mas não consegue corrigir — ele apenas detecta o erro (o que os pesquisadores chamam de “detectable uncorrectable error”, ou DUE) e, tipicamente, força a GPU a travar ou reiniciar para evitar usar um dado corrompido. É desagradável, mas não é uma porta de entrada — só que, segundo o paper, existe uma janela de cerca de dez milissegundos entre a detecção do erro e o encerramento efetivo do processo, tempo suficiente para um atacante consumir o dado já corrompido antes que a placa seja desligada.
O cenário mais grave, porém, acontece quando exatamente três bits são invertidos na mesma região protegida. Um código SECDED simplesmente não tem “vocabulário” para distinguir esse padrão de um erro de um bit só — e um erro de um bit é, por definição, algo que ele corrige sozinho. Resultado: o ECC “corrige” um erro que, na verdade, é outro, e devolve um dado errado com a garantia equivocada de que está correto. Os pesquisadores chamam esse resultado de corrupção silenciosa de dados (silent data corruption) — silenciosa porque não gera nenhum alerta, nenhum travamento, nada que denuncie que algo deu errado. Nos experimentos, a equipe conseguiu provocar centenas de erros de dois bits e alguns erros de três bits de forma controlada o suficiente para explorar ambos os caminhos.
O que isso significa na prática: root no host
A consequência mais séria demonstrada pelos pesquisadores não é apenas “a memória de vídeo fica instável”. Explorando essa corrupção controlada — seja pela janela de dez milissegundos após um erro de dois bits, seja pela correção incorreta de um erro de três bits — a equipe conseguiu realizar uma escalada de privilégios completa, obtendo acesso root no computador que hospedava a GPU, tanto com o ECC desligado quanto, mais notavelmente, com o ECC ligado e funcionando como recomendado pela própria NVIDIA. Em um dos cenários testados na RTX A6000, o tempo total para conseguir esse acesso caiu de cerca de 21,9 horas (com o método antigo do GPUHammer) para aproximadamente 1,1 minuto com o GPUThor.
Isso importa especialmente em um cenário cada vez mais comum: GPUs compartilhadas entre múltiplos usuários ou clientes, como acontece rotineiramente em serviços de nuvem voltados para treinamento de inteligência artificial. Se um atacante consegue rodar seu próprio código na mesma placa física que outros usuários — algo comum em GPUs “fatiadas” por tempo entre diferentes clientes de um provedor de nuvem —, o Rowhammer deixa de ser um problema teórico de laboratório e passa a ser um vetor real para corromper dados de terceiros ou tentar escapar do isolamento entre usuários.
Vale um recorte importante: até onde a pesquisa e a cobertura técnica confirmam, o GPUThor foi demonstrado contra placas profissionais Ampere com GDDR6 (RTX A4000, A4500, A5000 e A6000). GPUs de datacenter mais recentes, como A100 e H100, e a geração Blackwell (incluindo RTX 5090 e RTX 6000), usam outros tipos de memória (HBM, GDDR6X ou GDDR7) e não fazem parte do conjunto testado no artigo.
A resposta da NVIDIA e o que vem a seguir
Seguindo o modelo de divulgação responsável, os pesquisadores notificaram a NVIDIA em abril de 2026, meses antes de tornar o trabalho público, dando tempo para a fabricante avaliar o problema e preparar uma resposta. A divulgação pública aconteceu no fim de agosto de 2026, acompanhada de um aviso de segurança da própria NVIDIA recomendando medidas adicionais de mitigação — como isolamento de IOMMU/DMA no host e monitoramento ativo da telemetria de erros ECC das placas via ferramentas como o nvidia-smi — já que o ECC isoladamente deixou de ser garantia suficiente. O código do ataque e os artefatos completos da pesquisa têm lançamento público programado para coincidir com a apresentação na ACM CCS 2026, em novembro, em Haia, na Holanda.
A conclusão dos próprios autores é direta: defesas hoje consideradas padrão da indústria, como o ECC, podem ser contornadas com o desenho de ataque certo, e mitigar o Rowhammer em GPUs de forma duradoura provavelmente vai exigir mecanismos de proteção mais robustos do que os usados atualmente — do tipo já discutido para memória de servidor tradicional, como esquemas de correção mais fortes (por exemplo, do estilo “Chipkill”) ou técnicas de atualização de linha mais agressivas (como o chamado PRAC). Por ora, o episódio serve como lembrete de que, em segurança de hardware, uma defesa desenhada para um cenário específico pode falhar silenciosamente quando alguém encontra o padrão de ataque que ela não previu — e de que “ligar o ECC e esquecer o assunto” não é mais um conselho de segurança confiável para quem opera GPUs compartilhadas.
Fontes
Este artigo foi apurado a partir do artigo acadêmico original e de cobertura técnica especializada, verificados de forma independente:
Chris S. Lin, Joyce Qu, Aditya Rajeev e Gururaj Saileshwar (Universidade de Toronto), “GPUThor: Amplifying Rowhammer Attacks via Non-Uniform Patterns to Exploit ECC-Protected GPUs”, artigo aceito para a ACM CCS 2026 (The Hague, Holanda, 15 a 19 de novembro de 2026), disponível em gururaj-s.github.io e no site oficial do projeto, gputhor.com.
Chris S. Lin, Joyce Qu e Gururaj Saileshwar (Universidade de Toronto), “GPUHammer: Rowhammer Attacks on GPU Memories are Practical”, USENIX Security 2025, disponível em gpuhammer.com.
Cobertura técnica adicional consultada para verificação cruzada: The Hacker News, BleepingComputer e CSO Online. Também identificamos cobertura anterior em português sobre o mesmo tema no site brasileiro SempreUpdate, publicada em 27 de agosto de 2026 — este texto busca ir além do resumo factual e explicar em profundidade o mecanismo técnico por trás do ataque.