Nova vulnerabilidade no kernel, CVE-2026-43494 “PinTheft”, concede privilégios de root local quando o RDS e o io_uring estão expostos

A versão resumida

O que é: Uma nova vulnerabilidade de escalonamento de privilégios local no Linux chamada PinTheft. Ela combina um bug de contagem de referências (refcount) na rota de envio zerocopy do RDS (Reliable Datagram Sockets) do kernel com o io_uring para sobrescrever um binário SUID com privilégios de root na memória. O resultado é um shell com privilégios de root a partir de uma conta local sem privilégios. Nenhum CVE havia sido atribuído até o momento da publicação.

Impacto: Uma demonstração pública de conceito realizada pela V12 Security oferece a qualquer usuário local sem privilégios um caminho confiável para obter privilégios de root nos hosts afetados. A falha subjacente está presente no kernel do Linux desde a versão 4.17, lançada em 2018.

Situação: Aaron Esau, da V12 Security, empresa responsável pela descoberta, divulgou o PinTheft em maio, com um patch para o kernel já disponível. A correção candidata para o upstream foi publicada na lista de discussão do kernel netdev em 5 de maio de 2026. Foi atribuído o CVE-2026-43494, sem pontuação CVSS. Consulte a seção “Patch sem reinicialização do KernelCare” abaixo para saber o status atual.

Gravidade: Vetor local ; requer a capacidade de executar código no host como qualquer usuário local; sem interação do usuário. A exploração prática requer que todos os seguintes requisitos estejam presentes no alvo: RDS e RDS_TCP disponíveis e carregáveis, io_uring habilitado, um binário SUID-root legível e uma carga útil x86_64 (o PoC é específico da arquitetura, embora a técnica não seja). A V12 afirmou que, entre as distribuições comuns que testaram, o RDS só era carregável por padrão no Arch Linux. Outras distribuições fornecem o módulo com o carregamento automático bloqueado ou nem mesmo o compilam.

Por que isso é importante: A cadeia de exploração é confiável, a prova de conceito está disponível publicamente e ainda não há nenhum CVE nem comunicado oficial do fornecedor. Sistemas Linux multilocatários (hospedagem compartilhada, executores de CI, hosts de contêineres) nas distribuições afetadas devem ser considerados em risco imediato.

Faça isso agora: se o seu host não executar uma carga de trabalho RDS — e a maioria não executa —, bloqueie os módulos rds e rds_tcp com uma regra modprobe. Se o io_uring não for necessário e o seu kernel for 6.6 ou mais recente, você também pode desativá-lo com um comando sysctl. Os comandos de mitigação e o plano alternativo para kernels mais antigos estão abaixo.

A versão completa

A V12 Security publicou a demonstração de conceito do PinTheft e um artigo técnico em maio de 2026. Aaron Esau é creditado pela descoberta. A falha em si está presente no kernel do Linux desde a versão 4.17, em 2018, mas a cadeia de exploração depende de recursos do io_uring que ainda não existiam quando o bug foi introduzido.

A correção provisória do kernel foi enviada à lista de discussão do netdev em 5 de maio de 2026. Os kernels das distribuições derivadas ainda estão incorporando essa correção. A equipe de engenharia da KernelCare está preparando patches que não exigem reinicialização para os kernels afetados que estão sob suporte.

Algumas reportagens iniciais associaram o PinTheft especificamente ao kernel 6.13 e versões posteriores. Isso reflete as dependências do PoC divulgado, e não a duração da vulnerabilidade subjacente — o problema de contagem de referências na rota zerocopy do RDS é muito mais antigo, mas uma cadeia de exploração funcional que reproduza o PoC ainda requer recursos recentes do io_uring.

Como funciona a vulnerabilidade

Quando um programa envia dados por meio de um soquete de rede, o kernel normalmente copia esses dados da memória do programa para os buffers do kernel. Para economizar ciclos de CPU, os kernels modernos também oferecem o envio por “zerocopy”: o kernel bloqueia as páginas de memória do usuário e as utiliza diretamente. O RDS, um protocolo menos comum destinado a redes de data centers de alto desempenho, suporta esse modo zerocopy.

O bug está na forma como o RDS realiza a limpeza após uma falha no envio por zerocopy no meio do processo. O kernel acaba liberando as mesmas páginas duas vezes, em vez de uma. Cada envio com falha rouba uma referência da primeira página do usuário.

Por si só, isso é apenas um pequeno erro de contabilidade. O PinTheft transforma isso em uma vulnerabilidade de privilégios de root por meio do io_uring, a moderna interface de E/S assíncrona do Linux. O io_uring permite que um programa registre uma página de memória como um buffer fixo, o que adiciona 1.024 referências à página. O invasor, então, força 1.024 envios RDS zerocopy com falha para esgotar silenciosamente todas essas referências. O kernel agora acredita que ninguém está usando a página e a libera, mas o io_uring ainda mantém um ponteiro para ela.

Em seguida, o invasor executa qualquer binário SUID com privilégios de root. O kernel carrega esse binário na mesma página liberada em seu cache de páginas. Uma única gravação com io_uring no buffer desatualizado sobrescreve o binário na memória com o shellcode. Ao executar o binário SUID, o usuário passa a ter acesso a um shell com privilégios de root.

O arquivo no disco permanece inalterado. É a cópia do cache de páginas na memória que é sobrescrita. Isso é importante para a limpeza, conforme abordado na seção de mitigação.

O bug latente de contagem de referências parece remontar à introdução do suporte ao zerocopy do RDS no Linux 4.x. A exploração confiável, conforme demonstrado no PoC, depende adicionalmente de recursos mais recentes do io_uring (notadamente o IORING_REGISTER_CLONE_BUFFERS, disponível a partir da versão 6.12); portanto, embora o bug seja antigo, a janela de exploração prática é mais restrita.

Quem é afetado

O único aspecto que importa é se o kernel em execução consegue carregar os módulos RDS, e não o nome da distribuição. Verifique diretamente a configuração do kernel e a política de carregamento de módulos usando os comandos da próxima seção.

RDS carregável por padrão (confirmado pelos pesquisadores): Arch Linux.

O módulo RDS é fornecido, mas seu carregamento automático está bloqueado por padrão: Ubuntu (todas as versões atualmente suportadas, por meio de um arquivo de lista negra no pacote kmod), Debian 11 e 12 (por meio de um patch específico do Debian que desativa o carregamento automático do RDS como medida de mitigação contra explorações locais), Fedora (CONFIG_RDS=m, mas o módulo é fornecido no kernel-modules-extra e inclui seu próprio arquivo de lista negra). Nesses sistemas, o PoC requer que um administrador ou uma carga de trabalho carregue deliberadamente o rds_tcp primeiro. Testes independentes também indicam que carregar o módulo em um sistema padrão derivado do Debian nem sempre é suficiente para que o PoC seja bem-sucedido; portanto, o comportamento varia.

Requer verificação específica do fornecedor ou da configuração: Amazon Linux 2023, openSUSE Tumbleweed, Proxmox VE 7/8/9, Oracle Linux UEK 6 e 7. Verifique o arquivo CONFIG_RDS em /boot/config-$(uname -r) e procure pelas regras do modprobe fornecidas pelo fornecedor nos diretórios /etc/modprobe.d/ e /lib/modprobe.d/.

Não afetados: RHEL, AlmaLinux, Rocky Linux e CentOS Stream 8/9/10 que executam o kernel padrão compatível com a Red Hat — essas versões não incluem o RDS. O RHEL 9 e 10 também desativam o io_uring por padrão, removendo a outra metade da cadeia.

Uma ressalva que se sobrepõe a tudo o que foi dito acima: qualquer host que execute um kernel personalizado ou alternativo pode se comportar de maneira diferente da distribuição de origem. O Oracle Linux UEK, em particular, costuma ser executado em paralelo ao RHCK e apresenta uma configuração diferente.

Aja agora para mitigar

Existem duas medidas práticas de mitigação. Escolha uma delas dependendo se o seu provedor de hospedagem utiliza, de fato, o RDS ou o io_uring.

Recomendado para a maioria dos hosts: bloquear os módulos RDS

A grande maioria dos servidores Linux não utiliza o RDS. Ele é encontrado principalmente no Oracle Clusterware e em algumas configurações de HPC com InfiniBand. Em qualquer host que não execute uma carga de trabalho do RDS, a solução mais simples é impedir que os módulos rds e rds_tcp sejam carregados.

sudo sh -c "printf 'install rds /bin/false\ninstall rds_tcp /bin/false\n' > /etc/modprobe.d/pintheft.conf"
sudo rmmod rds_tcp rds 2>/dev/null || true

A vulnerabilidade sobrescreve o binário SUID apenas na memória. O arquivo no disco permanece inalterado. Em qualquer host que possa ter sido alvo do ataque antes da mitigação, esvazie o cache de páginas para eliminar quaisquer modificações na memória:

sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

Reverta após a aplicação do patch do kernel ou do livepatch do KernelCare:

sudo rm /etc/modprobe.d/pintheft.conf

Se você executar cargas de trabalho RDS ( Oracle Clusterware, determinadas pilhas de HPC), não aplique essa medida de mitigação. Utilize a alternativa io_uring abaixo ou aguarde o kernel corrigido.

Alternativa: desativar o io_uring em todo o sistema

O sysctl `kernel.io_uring_disabled` está disponível no Linux 6.6 e versões mais recentes. Os kernels de distribuições anteriores a essa versão — incluindo o Ubuntu 22.04 (5.15), Debian 11 (5.10) e 12 (6.1), Amazon Linux 2023 (6.1), RHEL 9 (5.14) e Ubuntu 24.04 (6.8 — verifique sua versão específica) — não disponibilizam esse sysctl.

Nesses kernels, bloquear os módulos RDS é a opção mais prática. Desativar completamente o io_uring em kernels mais antigos requer um parâmetro de inicialização ou uma recompilação do kernel e, em geral, não vale a pena o esforço em comparação com o bloqueio do RDS.

Se o io_uring não for necessário para suas cargas de trabalho, desative a outra metade da cadeia de exploração.

sudo sysctl -w kernel.io_uring_disabled=2

Essa é a configuração padrão no RHEL 10 e é o motivo pelo qual essa família de distribuições permanece fora do escopo, independentemente do estado do RDS. Observe que desativar o io_uring pode afetar alguns mecanismos de banco de dados modernos e cargas de trabalho de E/S assíncrona. Verifique em seu ambiente antes de aplicar a alteração.

Permanecer após reinicializações:

echo 'kernel.io_uring_disabled = 2' | sudo tee /etc/sysctl.d/99-pintheft.conf
sudo sysctl --system

Defesa em profundidade em hosts fortificados

Se sua carga de trabalho não carregar módulos do kernel em tempo de execução, definir `kernel.modules_disabled=1` após a inicialização impede que qualquer chamada futura ao `modprobe` seja bem-sucedida, o que desativa de uma só vez o carregamento automático do RDS e de todos os outros módulos.

Essa abordagem é mais agressiva do que colocar o RDS especificamente na lista negra e só deve ser usada quando não for esperado o carregamento de módulos em tempo de execução (sem hardware hot-plug, sem módulos de sistema de arquivos ou de rede sob demanda, sem ambientes de execução de contêineres que carreguem módulos na primeira utilização).

sudo sysctl -w kernel.modules_disabled=1

Observe que essa configuração é uma alteração irreversível durante a inicialização — ela não pode ser redefinida para 0 sem reiniciar o sistema. Teste em um ambiente que não seja de produção antes de implementar a mudança.

Verifique se o seu servidor está exposto

Execute as três verificações abaixo e compare os resultados com os critérios apresentados no final desta seção.

1. O RDS está disponível na compilação do kernel?

   grep -E 'CONFIG_(RDS|RDS_TCP|IO_URING)' /boot/config-$(uname -r)
   modprobe -n -v rds_tcp
   ls /lib/modules/$(uname -r)/kernel/net/rds/ 2>/dev/null

2. O io_uring está habilitado?

   cat /proc/sys/kernel/io_uring_disabled

3. Esses módulos já estão na lista negra?

   grep -rEn '^\s*(blacklist|install)\s+rds' /etc/modprobe.d/ /etc/modules-load.d/ 2>/dev/null

Um host só é considerado um alvo viável se todas as condições a seguir forem atendidas: CONFIG_RDS e CONFIG_RDS_TCP estiverem disponíveis, io_uring_disabled for 0 e os módulos rds e rds_tcp não estiverem na lista negra.

Patch KernelCare sem reinicialização

Esta seção é atualizada à medida que os patches são incorporados. Verifique a data e a hora na linha de atualização no início da postagem.

Situação em 21 de maio de 2026, às 12h UTC: os patches do KernelCare para todas as distribuições (exceto Debian 12 e Proxmox8) foram promovidos para o repositório principal.

Assim que estiver disponível no feed de testes:

kcarectl --update --prefix test

Após a validação, o patch é incluído na próxima execução programada ou pode ser baixado sob demanda:

kcarectl --update

Verifique se a correção foi aplicada. Assim que um CVE for atribuído, verifique usando:

kcarectl --patch-info | grep CVE-XXXX-XXXXX   # substitua pelo CVE

O que acompanhar à medida que a situação se desenrola

• Atribuição de CVE (nenhuma até o momento da redação deste texto)
• Um comunicado oficial da V12 Security ou da equipe de segurança do kernel
• Atualizações do kernel das distribuições Ubuntu, Debian, Amazon Linux, openSUSE, Oracle e Proxmox
• Lançamento da atualização do KernelCare em todas as linhas de kernel compatíveis

Esta publicação será atualizada assim que o CVE for atribuído e à medida que os patches do KernelCare passarem da fase de testes para a versão estável. Os clientes do KernelCare receberão o patch automaticamente assim que ele for promovido para o feed principal.

Aplique patches em todos os kernels, sem necessidade de reinicialização

Se você ainda não é usuário do KernelCare, este é um bom momento para descobrir como a aplicação de patches sem reinicialização pode proteger sistemas Linux críticos sem a necessidade de janelas de manutenção de emergência ou tempo de inatividade.

Saiba mais sobre o KernelCare aqui →