Não quer passar por uma quarta janela de reinicialização de emergência neste mês? O KernelCare aplica patches no kernel do Linux sem a necessidade de reinicialização, sem tempo de inatividade nem interrupções.
*Atualização (18/05/2026, 13h UTC): A KernelCare lançou patches que não exigem reinicialização para o Ubuntu 22.04 (Jammy), o Debian 11 (no ePortal), a família EL9 (nos canais test + main) e o RHEL 8/Rocky Linux 8 (no canal test)
A versão resumida
O que: Uma vulnerabilidade de escalonamento de privilégios local no Linux em __ptrace_may_access(), informalmente chamado de ssh-keysign-pwn (ou chage_pwn, em referência ao PoC do título). Nenhum CVE havia sido atribuído até o momento da publicação.
Impacto: A prova de conceito pública consegue, de forma confiável, elevar um usuário local sem privilégios ao nível de root, aproveitando a vulnerabilidade dos binários SUID por meio dessa brecha: chage vazar /etc/shadow, ssh-keysign vazar chaves privadas de hosts SSH.
Status: O correção na origem (confirmar 31e62c2) foi lançado na mesma janela que o divulgação pública na lista de discussão oss-security. Ainda não foi atribuído nenhum CVE, o comunicado da Qualys ainda não foi publicado e ainda não há pontuação CVSS. A KernelCare disponibilizou patches que não exigem reinicialização para o Ubuntu 22.04 (Jammy), o Debian 11 (no ePortal) e a família EL9 (nos repositórios test e main), RHEL 8/Rocky Linux 8 (no canal de testes).
Gravidade: Vetor local, sem necessidade de privilégios, sem interação do usuário, sem configuração especial. O PoC público funciona imediatamente no Debian 11/12/13, Ubuntu 22.04/24.04/26.04, Arch, Raspberry Pi OS Bookworm e nas famílias EL9 e EL10. O EL8 e o Ubuntu 20.04 estão vulneráveis, mas requerem um PoC adaptado. O EL7 com o kernel 3.10 não é afetado.
Por que isso é importante: como a vulnerabilidade tem como alvo binários SUID comuns e não requer privilégios nem interação do usuário, os sistemas Linux multiusuário vulneráveis devem ser considerados em risco imediato.
Faça isso agora: Apertar o Yama ptrace_scope nos servidores (um sysctl, reversível). KernelCare Os clientes devem ficar atentos ao lançamento do feed de testes. Os comandos de mitigação e as instruções para a aplicação de patches sem reinicialização estão abaixo.
A versão completa
Uma vulnerabilidade de acesso root no kernel do Linux foi divulgada no GitHub nesta manhã, sem um ID CVE associado, sem nenhum comunicado do pesquisador que descobriu a falha e com uma demonstração de conceito (PoC) pública que funciona em um sistema Debian ou Ubuntu padrão. O bug está em __ptrace_may_access(). A correção foi incorporada ao código-fonte original nesse mesmo período – uma boa notícia, exceto que ninguém fora das equipes do kernel das distribuições terá acesso a ela por alguns dias.
Aqui estão os detalhes mais precisos da linha do tempo. Jann Horn propôs uma correção equivalente para esse bug em 2020. Ela não foi incorporada. A causa raiz permaneceu em todos os ramos estáveis do kernel por cinco anos, até que um pesquisador da Qualys a redescobriu e um segundo pesquisador publicou dois exploits funcionais no repositório ssh-keysign-pwn poucas horas após a divulgação pelo upstream.
O patch do KernelCare que não requer reinicialização está em fase de compilação. Até que ele seja lançado, há um comando sysctl que bloqueia completamente o PoC público. Veja a seguir o que está acontecendo e o que fazer hoje.
Como funciona a vulnerabilidade
Uma refatoração de 2017 de __ptrace_may_access() (confirmar bfedb589, v4.10-rc1) inverteu silenciosamente a verificação de acesso quando uma tarefa mm é NULL. O código anterior à refatoração negava o acesso nesse estado. O código refatorado permite o acesso.
Durante a saída do processo, há um intervalo da ordem de microssegundos em que task->mm já foi liberada, mas os descritores de arquivo da tarefa ainda estão ativos. O PoC público executa um processo SUID nessa janela usando pidfd_open e pidfd_getfd, com dois alvos já definidos no repositório: chage vazar /etc/shadow, e ssh-keysign para vazar chaves privadas de hosts SSH. A taxa de acerto relatada é de 100 a 2.000 instâncias geradas por tentativa bem-sucedida.
Jann Horn propôs uma correção equivalente em 2020 (v1, v2). Ela não foi incorporada, e o bug permaneceu latente.
Quem é afetado
A regressão foi incorporada retroativamente à série estável v4.4.40; portanto, praticamente todos os kernels de distribuições modernas que não sejam EL7 estão abrangidos por padrão. Três grupos:
A demonstração de conceito (PoC) pública funciona imediatamente:
- Debian 11, 12, 13
- Ubuntu 22.04, 24.04, 26.04
- Arch Linux (atual)
- Raspberry Pi OS Bookworm
- CentOS Stream 9, AlmaLinux 9, RHEL 9, Oracle Linux 9, Rocky Linux 9
- AlmaLinux 10, RHEL 10
Vulnerável, mas a demonstração de conceito (PoC) precisa de adaptação:
- Família EL8 (RHEL 8, AlmaLinux 8, Rocky 8, Oracle Linux 8)
- Ubuntu 20.04
Não afetados:
- Família EL7 no kernel 3.10 – anterior à regressão de 2017
Aja agora para mitigar
Apertar o Yama ptrace_scope. A exploração acessa a falha por meio de pidfd_getfd(). pidfd_getfd() chamadas ptrace_may_access(…, PTRACE_MODE_ATTACH_REALCREDS), que executa o gancho LSM no final de __ptrace_may_access. Uma negação do Yama contorna o bug, independentemente da passagem pela instrução mm-NULL com erro.
O comum ptrace_scope=1 A configuração padrão (do Debian/Ubuntu, tal como vem de fábrica) NÃO é suficiente. Sob scope=1, a ligação de processo pai a filho é permitida. O invasor gera ele mesmo o processo SUID, portanto, ele são o pai ou a mãe. Você deve se mudar para scope=2 ou scope=3.
Recomendado: ptrace_scope=2 (anexo exclusivo para administradores, totalmente reversível em tempo de execução):
sudo sysctl -w kernel.yama.ptrace_scope=2
Reverta após a instalação do patch que dispensa a reinicialização:
sudo rm /etc/sysctl.d/99-ssh-keysign-pwn.conf
Mais forte: ptrace_scope=3 (sem anexo para ninguém, irreversível sem reinicialização):
sudo sysctl -w kernel.yama.ptrace_scope=3
scope=3 é uma ação irreversível até a reinicialização: o kernel rejeita tentativas posteriores de reduzi-lo (sysctl -w kernel.yama.ptrace_scope=2 retornos EINVAL). Escolha essa opção somente se você estiver disposto a reiniciar o sistema para reverter a ação e se o `root debug-attach` (gdb -p, strace -p (como root) não faz parte de suas operações normais.
Compatibilidade
scope=2interrompe os usuários sem privilégiosgdb -p/strace -p/perf trace --pide fluxos de depuração de contêineres O root mantém a conexão, portanto, o diagnóstico de problemas pelo administrador ainda funciona.scope=3impede o funcionamento do `debug-attach` para todos, inclusive o usuário root.
Patch KernelCare sem reinicialização
A KernelCare lançou patches que não exigem reinicialização para o Ubuntu 22.04 (Jammy), o Debian 11 (no ePortal), a família EL9 (nos repositórios test e main) e o RHEL 8/Rocky Linux 8 (no repositório test)
Assim que for publicado no feed de teste:
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
O que observar à medida que a situação se desenrola
- Atribuição de CVE: (nenhuma até o momento da redação deste artigo)
- O próprio comunicado da Qualys, que provavelmente conterá uma descrição técnica mais completa
- Atualizações do kernel de distribuição do Debian, do Ubuntu e dos fornecedores do EL9/10
- Novas alterações no repositório público ssh-keysign-pwn – é improvável que os dois alvos atuais sejam os únicos viáveis
Atualizaremos esta publicação assim que o CVE for divulgado e quando o patch do KernelCare passar da versão de teste para a estável. Se você estiver usando o KernelCare, o patch será instalado automaticamente, portanto, não é necessário fazer nada.
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.