O Infinity Core comprova que as partes “silenciosas” do kernel não estão a salvo

A versão resumida

Ir para a versão completa ↓

O que é: Infinity Core é o nome que Hyunwoo Kim (@v4bel) deu a seis falhas no código central do kernel, abrangendo temporizadores de CPU POSIX, entrega de sinais, o “page table walker”, futexes, contabilidade de cache do agendador e o alocador SLUB. Kim publicou os detalhes e o código de exploração no oss-security em 16 de outubro de 2026, assim que o embargo da lista linux-distros chegou ao fim. Ir para esta seção →

Impacto: Cinco das seis vulnerabilidades vêm acompanhadas de uma demonstração pública de conceito que começa com uma conta comum sem privilégios e termina com um shell de root. Kim também classifica essas mesmas cinco como fugas de contêiner. A sexta, no SLUB, até o momento apenas causa um panico no kernel. Ir para esta seção →

Gravidade: As pontuações não refletem bem essa realidade. O Amazon Linux atribui aos bugs relacionados ao temporizador e ao sinal uma pontuação de 7,0 segundo o CVSS 3.1 e ao bug MM uma pontuação de 6,3, todos com vetor de ataque local e alta complexidade de ataque. Essas classificações foram divulgadas antes que exploits de root funcionais fossem tornados públicos. Ir para esta seção →

Quem é afetado: O Ubuntu 26.04 é o mais afetado. As explorações de vulnerabilidades de nível root relacionadas aos bugs do timer, do signal, do MM e do futex foram criadas e testadas nessa versão 7.0.0-30-generic kernel, e a equipe de kernel da TuxCare também conseguiu reproduzir o acesso como root com todas as quatro versões no Ubuntu 26.04. O bug do temporizador também afeta os kernels EL9 e EL10, o Debian 12 e 13 e o Ubuntu 24.04, onde os testes da TuxCare causaram travamentos, mas não permitiram o acesso como root — pelo menos não ainda. Os bugs do agendador e do SLUB só existem na versão 7.2 e posteriores. Ir para esta seção →

Status: Já existem correções no código-fonte para todas as seis vulnerabilidades, e quatro dos registros CVE já haviam sido divulgados publicamente entre 4 de setembro e 6 de outubro. Os kernels das distribuições estão se atualizando de forma desigual. O Debian, por exemplo, já disponibilizou kernels corrigidos para as vulnerabilidades “bookworm” e “trixie”, e a Red Hat corrigiu o bug “futex” para o RHEL 9 já em 1º de outubro. Não há relatos de exploração na natureza. Trata-se de vulnerabilidades “n-day” com exploits públicos, e não de “zero-day”.

Faça isso agora: não há nenhum sysctl ou módulo conhecido para desativar. Primeiro, instale kernels corrigidos nos hosts do Ubuntu 26.04, começando por aqueles que executam código de pessoas em quem você não confia totalmente, como servidores de hospedagem compartilhada, executores de CI e hosts de contêineres multilocatários. Se a sua distribuição já vier com uma correção, instale-a e planeje a reinicialização. Desativar os namespaces de usuários sem privilégios não ajudará, já que nenhum desses bugs depende disso. Para verificar qual kernel está realmente em execução:

uname -r

Compare isso com as orientações do seu fornecedor, e não com os números das versões do desenvolvedor original. Os kernels das distribuições incorporam correções retroativas sem aumentar o número da versão base.

Ir para esta seção →

Muitas das escaladas de privilégios no kernel que ganham destaque na mídia têm origem nas mesmas poucas áreas: redes, sockets, BPF e perf. São bugs que precisam acessar um namespace de usuário sem privilégios. Os guias de fortificação passaram anos ensinando os administradores a isolar essas áreas, e muitas empresas fizeram exatamente isso.

O Infinity Core ignora tudo isso. Kim deixou essas áreas de fora propositalmente e foi procurar no código todos os processos que são executados sem hesitação, como, por exemplo, exec(), tratamento de sinais, mincore() e futexes. O resultado foi: quatro vulnerabilidades que permitem acesso root em uma instalação padrão do Ubuntu 26.04, mais uma no Arch Linux e nenhuma configuração conhecida do sysctl ou de módulo que faça com que elas desapareçam.

As correções já foram incorporadas ao código-fonte original. O que falta em muitos servidores é um kernel em execução que as inclua.

O que chegou no dia 16 de outubro

Kim relatou os bugs de forma privada, tratou deles por meio da lista linux-distros e os publicou assim que o embargo expirou, em 16 de outubro de 2026. A postagem no oss-security e o repositório InfinityCore contêm descrições detalhadas de cada bug e o código de exploração. Esta também não é a primeira aparição de Kim neste blog. O mesmo pesquisador descobriu o Januscape e o Zapscape, as falhas de segurança do KVM identificadas no início deste ano.

Quatro dos seis já possuíam registros públicos no CVE antes do dia da divulgação. O CNA do kernel publicou o CVE do futex em 4 de setembro, o do MM em 11 de setembro e os CVEs do timer e do signal em 6 de outubro. Cada um deles foi divulgado com aquele tipo de título seco, no estilo de commit, comum aos CVEs do kernel, sem nada que sugerisse que uma exploração de privilégios de root estava por vir. Um CVE que parece um patch de limpeza é fácil de deixar de lado até a próxima janela de manutenção. O mesmo CVE com uma exploração de privilégios de root disponível no GitHub, porém, não é.

Ainda há uma falha que não foi divulgada. Kim afirma que a falha no temporizador também concede acesso root total em um Samsung Galaxy S26 Ultra a partir de um aplicativo comum, e que essa vulnerabilidade permanecerá em sigilo até que a Samsung lance uma correção ou alguém mais a publique primeiro.

Os bugs do temporizador e do sinal compartilham um gatilho, e ele é um tanto peculiar. Quando uma thread que não é a líder do processo chama exec() e, quando o processo avança o suficiente, o kernel troca os IDs das threads para que a thread chamadora assuma o papel de nova líder. Ambos os bugs estão presentes na limpeza realizada em torno dessa troca.

O CVE-2026-98260, o bug do temporizador, requer que um temporizador de CPU POSIX específico para cada thread esteja ativado nessa thread. Se exec() se falhar após a troca de IDs, o temporizador é liberado enquanto seu nó ainda está na fila de uma tarefa ativa e, posteriormente, o processo de limpeza acessa diretamente esse nó liberado. Um caso clássico de “use-after-free”. A exploração pública transforma isso em um shell com privilégios de root no Ubuntu 26.04, e a correção, acb03d388181, transfere a limpeza do temporizador para logo após de_thread() para que nada fique em aberto quando exec() fianças.

CVE-2026-98256, o bug de sinal, é uma corrida pelo mesmo momento. Um caminho libera os sinais pendentes do líder que está saindo sem adquirir um bloqueio, enquanto outro segue o PID trocado e vincula um sigqueue entrada na fila do novo líder. Se os links forem corrompidos, uma entrada permanece ativa por mais tempo do que o objeto ao qual pertence. A exploração de Kim usa essa entrada remanescente como um oráculo para detectar quando a memória liberada foi reutilizada e, em seguida, se aproveita do caminho que retira da fila o sinal manipulado para obter um shell de root. A correção é d2710c8d938a.

Os programas falham exec() o dia inteiro. Um caminho incorreto, um interpretador ausente, um sinal no momento errado. No entanto, nenhum desses erros ocorre por conta desses fatores isoladamente. O erro do temporizador requer que a falha ocorra após a troca do ID da thread, e o erro do sinal exige que um invasor vença uma corrida de acesso em torno dessa mesma troca. Visto de fora, uma tentativa ainda se parece com uma atividade normal do processo, e é por isso que não há uma maneira clara de filtrá-la, a não ser por meio de um patch.

A vulnerabilidade CVE-2026-89754 está localizada no “page table walker”. Durante uma situação de corrida com madvise(MADV_DONTNEED), um sinalizador de nova tentativa de um nível inferior se propaga para cima, e mincore() percorre o mesmo intervalo duas vezes. Nesse momento, seu cursor de saída já seguiu em frente, de modo que a segunda passagem grava além de um buffer temporário que tem exatamente o tamanho de uma página. A exploração de Kim aloca um bloco de credenciais na próxima página física e usa o estouro para zerar os campos UID e GID de um struct cred. Não dá para ser mais direto do que isso em relação ao LPE do kernel. A correção é aedf2efd1897.

O CVE-2026-80775, a falha no futex, requer que duas tarefas compartilhem um mm_struct, que estava aninhado vfork() ocorre assim que o “filho do meio” é eliminado. Ambos correm para instalar o primeiro contador de referências para o hash futex privado. Apenas um armazenamento sobrevive; assim, as referências feitas ao outro contador deixam de ser rastreadas, e um hash que ainda está em uso é liberado. A exploração o recupera por meio de um “pipe ring” e sobrescreve o cache de páginas de /usr/bin/passwd. Isso altera o que o kernel exibe para o arquivo sem gravar a alteração no disco; portanto, a adulteração pode desaparecer assim que a página em cache for liberada ou o servidor for reiniciado. Boa sorte ao investigar isso depois. A solução é bde023808364.

Os dois últimos são menos relevantes para a maioria das frotas. O CVE-2026-98385 é uma vulnerabilidade do tipo “use-after-free” na contabilidade do cache do agendador que requer CONFIG_SCHED_CACHE=y na compilação, a contabilidade do cache do agendador ativada em tempo de execução e uma topologia de CPU com mais de um cache de último nível. A exploração conseguiu privilégios de root no Arch Linux com um kernel 7.2.4. A CVE-2026-97941 é uma condição de corrida (race condition) do tipo ABA no reabastecimento de objetos SLUB que corrompe uma lista parcial. Seu gatilho público apenas causa um panic no kernel, e nenhuma exploração de privilégios de root foi publicada para ela. Ambas estão presentes em código que surgiu pela primeira vez na versão 7.2; portanto, nenhum kernel de distribuição compatível com o KernelCare contém nenhuma delas.

A pontuação do NVD ainda estava pendente para os bugs relacionados ao temporizador e aos sinais no momento da redação deste artigo. O Amazon Linux publicou pontuações para três deles, atribuindo 7,0 aos bugs relacionados ao temporizador e aos sinais com o vetor AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H, e 6.3 devido ao bug do MM.

O AC:H Essa parte merece uma análise mais atenta. A maioria delas envolve uma “corrida”, e “é uma corrida” costumava ser um motivo válido para rebaixar algo na fila. Uma vulnerabilidade divulgada publicamente, que já fez o trabalho pesado de vencer a corrida, muda o cenário. Uma vulnerabilidade 7.0 com um shell de root funcional associada, em um host onde usuários não confiáveis podem executar código, merece um lugar próximo ao topo da lista. Isso diz mais sobre a urgência do que o próprio número.

Quem deve se preocupar primeiro

Cada uma dessas contas começa como uma conta local simples, sem privilégios, sem namespace de usuário e sem acesso a dispositivos especiais. Portanto, a verdadeira questão é: quem pode executar código em seus hosts que você não controla totalmente?

Servidores de hospedagem compartilhada com shells SSH ou de painel de controle dos clientes são a resposta óbvia. Executores de CI que criam pull requests arbitrárias são outra. O mesmo vale para qualquer host que execute contêineres para locatários que não confiam uns nos outros. Kim classifica todos os cinco bugs de root como fugas de contêiner, e isso faz sentido. Todo contêiner compartilha o kernel do host, e as chamadas de sistema envolvidas são aquelas comuns que as cargas de trabalho dos contêineres utilizam constantemente. A menos que um perfil seccomp ou uma política LSM bloqueie exatamente esse caminho, não conte com a barreira do contêiner para te proteger.

Um servidor de banco de dados de finalidade única com três administradores é um caso à parte. Ele ainda precisa da correção. Só que não é a prioridade no momento.

O Infinity Core é uma vulnerabilidade de dia zero?

Não. Todas as correções já estavam no código-fonte antes que as vulnerabilidades fossem divulgadas, e o registro CVE mais antigo é anterior à divulgação em cerca de seis semanas. Não há relatos de exploração na natureza. Trata-se de vulnerabilidades do tipo “n-day” com exploits públicos, o que pode colocar os defensores em uma situação ainda pior. O prazo agora depende da rapidez com que as distribuições lançam kernels corrigidos e da rapidez com que os administradores realmente os instalam.

Informações sobre as distribuições com suporte do KernelCare em 19 de outubro de 2026, com base na análise própria da TuxCare e independentemente do status do kernel de cada fornecedor:

A expressão “falhas até o momento” requer uma ressalva. Uma vulnerabilidade de root funcional em uma versão do kernel representa uma grande vantagem inicial para a próxima, mesmo que adaptá-la ainda exija um esforço considerável. Ainda não foi comprovado que haja acesso root nessas distribuições, mas a escalada de privilégios local é um risco concreto nelas, e a prioridade na aplicação de correções deve refletir isso.

Como mencionado no início, uma string de versão por si só não resolve nada neste caso. Somente um comunicado do fabricante ou um patch verificado para esse kernel específico resolve.

Adquira o KernelCare hoje mesmo →

Por que não há uma solução rápida

Para muitos dos recentes LPEs do kernel, a solução provisória consistia em uma única linha de código. Colocar um módulo na lista negra, alterar um sysctl, desativar os namespaces de usuários sem privilégios. Nada disso funciona desta vez. Kim omitiu propositalmente os bugs que exigem um namespace de usuário, e o restante está em exec(), tratamento de sinais, mincore() e código futex que nenhum sistema em funcionamento consegue descarregar ou desativar. A TuxCare ainda não identificou uma solução alternativa confiável. As medidas habituais, como desativar os namespaces de usuários sem privilégios ou colocar um módulo na lista negra, não afetam os caminhos de código vulneráveis, e nenhuma solução alternativa específica foi verificada para cada bug.

Isso nos deixa com as opções menos satisfatórias. Reduzir o número de usuários que possuem um shell local em hosts expostos até que sejam corrigidos. Transferir os usuários que realmente não confiam uns nos outros para VMs separadas, em vez de contêineres em um kernel compartilhado. E ficar de olho no log do kernel. Várias dessas situações envolvem disputas de acesso, e uma tentativa fracassada pode causar um “oops” ou um “panic” no kernel, em vez de falhar silenciosamente; embora um log limpo não prove que nada tenha acontecido:

journalctl -k | grep -iE 'BUG:|Oops|general protection'

Um erro inexplicável ocorrido esta semana em um servidor multiusuário merece uma análise mais detalhada.

A solução definitiva é um kernel que inclua os patches do upstream, seja da sua distribuição ou de uma compilação própria. A instalação do pacote não altera o kernel que já está em execução na memória; portanto, até que o host reinicie com o novo kernel, nada muda. Verifique o que está realmente em execução:

uname -r

Um servidor que instalou um kernel corrigido e nunca foi reiniciado ainda está executando a versão vulnerável. Servidores de hospedagem compartilhada e pools de infraestrutura como código (CI) costumam ser os que mais apresentam esse problema, pois reiniciá-los implica avisar os clientes ou interromper as tarefas em andamento.

Uma vez lançados para o seu kernel, os patches sem reinicialização do KernelCare aplicam a correção ao kernel em execução sem a necessidade de reinicialização. Quando as atualizações automáticas estão ativadas, um patch é detectado na próxima verificação programada assim que estiver disponível no feed para o kernel em execução, e kcarectl --update solicita isso quando necessário. Para verificar a cobertura das quatro falhas que afetam os kernels das distribuições compatíveis:

kcarectl --patch-info | grep -E 'CVE-2026-(98260|98256|89754|80775)'

As vulnerabilidades (CVEs) relacionadas ao agendador e ao SLUB foram propositalmente excluídas desse padrão, uma vez que nenhum kernel de distribuição compatível as contém. Até 19 de outubro de 2026, o único patch do Infinity Core lançado é a correção do futex para um stream do kernel do AlmaLinux 9. Ainda não foi lançado nada para o bug do temporizador em nenhuma distribuição, nem para os quatro bugs no Ubuntu 26.04. Confira esta publicação para obter atualizações nos próximos dias. Assim que um patch chegar à sua versão do kernel, confirme se o KernelCare realmente o aplicou ao kernel em execução e mantenha o acesso restrito até que a cobertura das CVEs relevantes seja verificada.

Por que o Infinity Core é importante

O endurecimento por subtração tem um limite máximo. Os administradores se tornaram hábeis em eliminar a superfície de ataque desnecessária, e esse trabalho vale a pena. Mas ninguém consegue remover exec(). Kim foi à caça em subsistemas com um histórico de segurança discreto e voltou com seis falhas. Código maduro e amplamente utilizado não é sinônimo de código seguro, e o fortalecimento de segurança, por si só, não é suficiente para preencher essa lacuna.

Se você estiver executando o Ubuntu 26.04 com usuários locais não confiáveis, essa é a primeira atualização a ser feita esta semana. Em hosts EL, Debian e Ubuntu 24.04, dê prioridade máxima ao bug do temporizador, mesmo que os testes tenham gerado apenas travamentos até o momento, já que a vulnerabilidade pública do Ubuntu torna o acesso como root um próximo passo provável. E quando uma reinicialização significa esgotar um pool de CI ou enviar e-mails para algumas centenas de clientes de hospedagem, os patches sem reinicialização da KernelCare têm como objetivo corrigir esses bugs no kernel em execução à medida que a cobertura chega, sem a necessidade de uma janela de manutenção.

Adquira o KernelCare hoje mesmo →

Linha do tempo

Referências

A publicação de Kim sobre o Infinity Core no oss-security (16 de outubro de 2026), o repositório do InfinityCore com código de exploração e descrições por bug, os registros CVE para CVE-2026-98260, CVE-2026-98256, CVE-2026-89754, CVE-2026-80775, CVE-2026-98385 e CVE-2026-97941, o conjunto completo de commits de correções do upstream listados no repositório de Kim, incluindo a correção do temporizador acb03d388181 e a correção do futex bde023808364, a entrada no rastreador de segurança do Debian para o CVE-2026-98260, o RHSA-2026:74438 da Red Hat e a pontuação do Amazon Linux para CVE-2026-98260, CVE-2026-98256 e CVE-2026-89754.