PinTheft: falha no RDS do Linux permite escalada de privilégios até root

Onde está a falha no kernel

O bug está no RDS (Reliable Datagram Sockets), um protocolo de rede usado principalmente em ambientes de alto desempenho, como clusters com InfiniBand ou sistemas distribuídos de baixa latência.

A vulnerabilidade aparece no caminho de envio zerocopy do RDS, uma otimização que permite enviar dados diretamente da memória do usuário sem copiar buffers extras dentro do kernel. Essa técnica melhora desempenho, mas torna o gerenciamento de memória mais complexo.

Durante esse processo, a função do kernel rds_message_zcopy_from_user() fixa (pin) páginas de memória do usuário uma a uma antes do envio. Se ocorrer um page fault enquanto novas páginas estão sendo fixadas, o código de tratamento de erro tenta liberar as páginas já utilizadas — mas em certas condições faz isso de forma incorreta, causando double‑free ou corrupção de contadores de referência.

Esse estado inconsistente de memória abre caminho para a escalada de privilégios.

Como o exploit PinTheft funciona

Pesquisadores demonstraram que o bug do RDS pode ser combinado com recursos modernos de I/O do Linux para produzir um exploit relativamente confiável.

1. Acionando o bug de zerocopy do RDS

O atacante local aciona o caminho vulnerável do RDS. Se ocorrer um erro durante a fixação das páginas de memória, o kernel libera páginas que ainda deveriam estar em uso, criando uma condição de memória reutilizável de forma indevida.

2. Reutilização das páginas com io_uring

Em seguida entra o io_uring, interface moderna de I/O assíncrona do Linux. O exploit utiliza o recurso de fixed buffers, que permite registrar regiões de memória para operações de I/O de alta performance.

Manipulando esses buffers cuidadosamente, o invasor consegue realocar as páginas físicas liberadas pelo bug, ganhando controle indireto sobre elas.

3. Transformando a corrupção em sobrescrita do page cache

Essas páginas podem pertencer ao page cache, a estrutura que mantém dados de arquivos em memória para acelerar leitura e execução.

Com isso, o invasor pode alterar o conteúdo que o kernel entrega ao sistema sem modificar o arquivo no disco — apenas a versão em cache na memória.

4. Alterando um binário SUID‑root

O exploit então mira um executável SUID‑root presente no sistema. Ao alterar o conteúdo desse arquivo dentro do page cache, o kernel acaba executando código modificado com privilégios de root, mesmo que o arquivo original permaneça intacto no disco.

Quando o binário é executado, o atacante obtém acesso root completo.

Sistemas potencialmente mais afetados

A vulnerabilidade depende muito da configuração do sistema.

Arch Linux

Relatórios de segurança apontam o Arch Linux como um dos ambientes mais expostos porque:

• Um exploit funcional foi demonstrado nessa distribuição.
• O módulo RDS pode estar disponível dependendo da configuração do kernel.

Isso fez com que sistemas Arch fossem usados como alvo inicial para testes e demonstrações.

Sistemas com módulo RDS habilitado

Qualquer distribuição Linux pode teoricamente ser afetada se:

• estiver usando um kernel vulnerável
• e o módulo RDS estiver disponível ou carregado.

Distribuições empresariais

Instalações padrão de Ubuntu, Debian, RHEL e AlmaLinux tendem a ter menor exposição porque o módulo RDS geralmente não é habilitado por padrão. Mesmo assim, administradores devem verificar a configuração específica do kernel em uso.

Plataformas CloudLinux

A equipe da CloudLinux informou que testou o exploit público em várias versões da plataforma e concluiu que seus sistemas não são afetados.

Condições necessárias para exploração

Para que o ataque funcione, normalmente é preciso que vários fatores estejam presentes ao mesmo tempo:

• execução local de código por um usuário não privilegiado
• kernel Linux vulnerável com o bug no RDS zerocopy
• módulo RDS disponível ou carregado
• acesso de usuários não privilegiados ao io_uring
• presença de um binário SUID‑root que possa ser alvo do ataque via page cache

Se uma dessas condições não estiver presente, a exploração se torna muito mais difícil — ou impossível.

Como se proteger

Administradores podem reduzir significativamente o risco adotando algumas medidas práticas.

Atualizar o kernel

Os mantenedores do kernel já disponibilizaram correções para o código vulnerável do RDS. Instalar a atualização mais recente do kernel fornecida pela distribuição é a principal defesa.

Como atualizações do kernel exigem reinicialização, é necessário reiniciar o sistema após aplicar o patch.

Desabilitar o módulo RDS

Se a infraestrutura não utiliza RDS, a superfície de ataque pode ser reduzida ao:

• bloquear o carregamento do módulo rds
• removê‑lo de configurações de auto‑load

Restringir io_uring para usuários não privilegiados

Como o exploit depende de io_uring fixed buffers, limitar ou desabilitar o uso dessa interface para usuários comuns pode diminuir o risco em ambientes compartilhados.

Revisar binários SUID

Como a fase final do ataque depende de executáveis SUID‑root, vale auditar quais programas realmente precisam dessa permissão e remover o bit SUID quando não for necessário.

Priorizar sistemas multiusuário

Servidores com múltiplos usuários — como ambientes de CI/CD, hospedagem compartilhada ou máquinas de desenvolvimento — devem receber prioridade em atualizações e hardening, já que a vulnerabilidade exige execução local.

O que essa falha revela sobre segurança no kernel

O PinTheft mostra uma tendência crescente em exploits modernos: combinar vários subsistemas avançados do kernel para transformar um bug aparentemente pequeno em uma escalada de privilégios poderosa.

Neste caso, a combinação de RDS (rede) com io_uring (I/O assíncrono) permitiu transformar um erro de gerenciamento de memória em controle sobre o page cache e execução como root. Isso reforça uma lição importante para administradores: manter o kernel atualizado e reduzir módulos desnecessários continua sendo uma das defesas mais eficazes contra vulnerabilidades desse tipo.