O GhostLock transforma uma falha do Futex, que existe há 15 anos, em um shell de root

A versão resumida

Ir para a versão completa ↓

O que é: O GhostLock (CVE-2026-43499) é uma vulnerabilidade do tipo “use-after-free” no código de herança de prioridade do futex do kernel do Linux, o recurso de bloqueio por trás do PTHREAD_PRIO_INHERIT mutexes. Uma etapa de limpeza apaga os registros da thread incorreta, deixando uma thread ativa apontando para uma memória já liberada. O que é incomum é que essa memória fica no kernel pilha, e não no heap, onde a maioria desses bugs se encontra. Ir para a versão completa →

Impacto: Escalada de privilégios local até o nível de root. O exploit público de cadeia completa da Nebula Security alcança o nível de root a partir de um processo sem privilégios em cerca de cinco segundos, com uma confiabilidade de aproximadamente 97%. Reproduzimos o gatilho e o DoS local no Debian 11/12/13, EL7 e EL10; presumimos que qualquer kernel afetado seja passível de exploração até o nível de root, e não apenas suscetível a DoS. Ir para a versão completa →

Gravidade: CVSS 7,8 (Alta). Vetor local, baixa complexidade, sem interação do usuário e uma cadeia LPE pública altamente confiável em alvos compatíveis. A Red Hat classifica a vulnerabilidade como “Importante”. Ir para a versão completa →

Quem é afetado: O único pré-requisito é CONFIG_FUTEX_PI=y, ativado por padrão em todas as principais distribuições; não são necessárias capacidades especiais, namespaces nem hardware específico. Introduzido no Linux 2.6.39-rc1 (maio de 2011), com o intervalo vulnerável abrangendo até a versão v7.1-rc1; portanto, praticamente todos os kernels em produção estão sujeitos a essa vulnerabilidade. Ir para a versão completa →

Falha relacionada: Uma alteração subsequente, 74e144274af3 (CVE-2026-53166) foi posteriormente revertida no código-fonte original devido a uma regressão. Verifique a cobertura do GhostLock por meio do CVE-2026-43499 e da correção principal 3bfdc63936dd. Ir para a versão completa →

Status: Uma vulnerabilidade de N dias, não uma de zero dia. Relatada em 18 de abril, corrigida no código-fonte em 20 de abril (3bfdc63936dd), e retroaplicado em 4 de maio, tudo isso antes da divulgação pública em 7 de julho. Já existe um exploit funcional disponível ao público e a falha já foi divulgada na imprensa especializada em segurança. Ir para a versão completa →

Faça isso agora: não há nenhuma medida de mitigação em tempo de execução que abranja todo o host; o recurso vulnerável está compilado e não pode ser desativado em um kernel em execução. Aplique um kernel corrigido pelo fabricante ou um patch da KernelCare que não exija reinicialização. Em contêineres, um filtro seccomp que bloqueie as operações futex PI elimina o gatilho, mas isso pode interromper as cargas de trabalho que utilizam esses bloqueios. Ir para a versão completa →

Há duas razões que podem levá-lo a classificar esse ticket como de baixa prioridade, e ambas estão erradas.

A primeira é a idade do código. O GhostLock está presente em uma rotina de bloqueio lançada em maio de 2011. Um bug que permaneceu oculto por quinze anos parece uma curiosidade teórica, o tipo de descoberta que garante uma apresentação em uma conferência, mas nunca chega a afetar um servidor de produção. Essa visão é confortável, mas incorreta. O bug pode ser acessado a partir de um processo sem privilégios em um kernel padrão, e existe um exploit público de cadeia completa que o transforma em um shell de root em segundos.

A segunda é a palavra “futex”. Um futex (mutex rápido no espaço do usuário) é o componente básico do kernel que bibliotecas como a glibc utilizam para implementar bloqueios entre threads. Parece algo muito técnico, com o qual a maioria dos aplicativos nunca entra em contato diretamente, e isso é verdade, mas o recurso que está no centro desse bug — o bloqueio com herança de prioridade — não é algo restrito a um nicho específico. CONFIG_FUTEX_PI está habilitado por padrão em todas as principais distribuições; a glibc o utiliza para PTHREAD_PRIO_INHERIT mutexes, e o caminho vulnerável pode ser acessado sem capacidades, namespaces ou hardware especial. Se o seu kernel estiver na faixa afetada e tiver sido compilado com a configuração padrão, a vulnerabilidade está presente.

O GhostLock é a segunda publicação da série de pesquisas “IonStack” da Nebula Security, divulgada publicamente em 7 de julho de 2026 pela equipe identificada como VEGA, acompanhada de um relatório completo, uma entrada na lista de bugs e uma prova de conceito pública de cadeia completa. A descoberta rendeu uma recompensa do Google kernelCTF no valor de US$ 92.337 em 30 de junho. Nós o identificamos na manhã de 8 de julho, e um engenheiro da KernelCare iniciou a reprodução em várias distribuições no mesmo dia.

Uma observação importante a se ter em mente antes de entrarmos nos detalhes: trata-se de um bug do kernel principal, não de uma peculiaridade da distribuição. Qualquer kernel, desde a versão 2.6.39-rc1 até a 7.1-rc1, compilado com o PI futex contém o código vulnerável. A exploração divulgada é específica para determinada plataforma em suas etapas finais, mas a falha subjacente é praticamente universal.

Como funciona o GhostLock

Comece pela parte do kernel envolvida. Quando uma thread aguarda um bloqueio com herança de prioridade, o kernel rastreia essa relação em um pequeno registro chamado “waiter” e registra na thread em espera em qual bloqueio ela está bloqueada (um campo chamado pi_blocked_on). É importante manter essa contabilidade em ordem, pois, se um thread for encerrado ainda marcado como bloqueado em um bloqueio que não existe mais, o kernel ficará com um ponteiro apontando para o nada.

A rotina de limpeza, remove_waiter(), foi escrito para o caso mais simples: uma thread limpando sua própria espera. Ele pressupõe que a thread responsável pela limpeza, que o kernel chama de current, é a mesma thread que estava aguardando. Uma operação mais avançada chamada requeue-PI contraria essa suposição. O requeue-PI move uma thread em espera de um bloqueio para outro (é assim que as variáveis de condição são implementadas de forma eficiente), o que significa que a thread que está executando a limpeza é a que realiza a movimentação, e não aquela que estava aguardando.

Aqui está o erro. Quando o kernel detecta que uma requeue causaria um impasse (um ciclo em que cada thread aguarda a próxima) e encerra a operação com um erro, o caminho de reversão chama remove_waiter(), e remove_waiter() limpa current->pi_blocked_on, o de mudança registro, em vez do do garçom real. A thread de espera nunca é liberada. Quando ela retorna ao espaço do usuário, sua pi_blocked_on ainda aponta para seu próprio quadro de pilha, que o kernel já recuperou para outro uso. Esse ponteiro pendente na memória da pilha liberada é o que se chama de “use-after-free”.

Em linhas gerais, a exploração se baseia nisso da seguinte forma:

[Unprivileged process, three threads/futexes]
│  stage a deadlock cycle so the kernel takes the buggy rollback path
▼
[remove_waiter() clears the wrong thread's record → a live thread points into its own freed stack frame]
│
▼
[Reclaim that freed frame with attacker-controlled data → forge a fake waiter record]
│
▼
[Trigger the cleanup again → write one attacker-chosen pointer into a kernel network table]
│
▼
[Point that table entry at attacker code → send one IPv6 UDP packet to run it]
▼
[Flip a system setting (core_pattern) so a crash handler runs as root → root shell]

Explicando o mecanismo para os leitores que quiserem saber: o invasor provoca o impasse usando três threads e futexes por meio do FUTEX_LOCK_PI, FUTEX_WAIT_REQUEUE_PI, e FUTEX_CMP_REQUEUE_PI operações, o que obriga o -EDEADLK (impasse) retornar e a reversão com erros. Em seguida, eles recuperam o quadro de pilha liberado usando PR_SET_MM_MAP, uma chamada de controle de processo que permite que um programa defina campos que o kernel copia para sua própria pilha, preenchendo essa memória com um valor falsificado rt_mutex_waiter registro. A limpeza da árvore de espera do kernel passa, então, a ser uma única gravação controlada no ponteiro, destinada a inet6_protos[IPPROTO_UDP], a entrada da tabela que informa ao kernel qual função processa os pacotes UDP IPv6 recebidos. O invasor direciona essa entrada para uma instrução “pivot” localizada em um endereço fixo e previsível (a Área de Entrada da CPU, uma região específica para cada CPU que sempre fica em um local conhecido) e, em seguida, envia um pacote UDP IPv6 para invocá-la. Isso transfere o controle para uma cadeia de programação orientada a retorno (que une fragmentos de código existentes do kernel para executar lógica arbitrária), e a etapa final inverte as permissões no core_pattern configuração que controla qual programa é executado quando um processo trava, de modo que o manipulador de falhas do invasor seja executado como root.

As funções envolvidas são remove_waiter(), rt_mutex_start_proxy_lock(), e rt_mutex_adjust_prio_chain() em kernel/locking/rtmutex.c. O bug em questão é um “use-after-free” na pilha do kernel, que leva à escalada de privilégios locais. Vale a pena dar uma pausa para refletir sobre o termo “pilha” nesse contexto: a maioria dos bugs do tipo “use-after-free” exploráveis corrompem objetos da pilha dinâmica, onde o layout é relativamente fácil de manipular. Recuperar um objeto específico que foi liberado pilha Um frame com conteúdo controlado é mais difícil de se obter e menos comum, o que explica em parte por que esse bug é interessante e, nas mãos do pesquisador, ainda confiável.

O que a correção do Upstream altera

A correção principal consiste em uma alteração de uma linha. Antes do patch, o rollback de deadlock limpava o registro de bloqueio da thread errada. Depois disso, remove_waiter() limpa waiter->task->pi_blocked_on (o registro do garçom de verdade) em vez de current->pi_blocked_on (da função que move), de modo que a liberação não deixa mais um thread ativo apontando para a memória da pilha que foi liberada.

Conceitualmente:

Before:  deadlock rollback → clear the mover's record → real waiter left pointing at freed memory → use-after-free
After:   deadlock rollback → clear the real waiter's record → nothing left dangling

O commit anterior é 3bfdc63936dd (“rtmutex: Use waiter::task em vez de current em remove_waiter()”). Uma alteração subsequente, 74e144274af3, foi rastreada separadamente como CVE-2026-53166, mas foi posteriormente revertida no código-fonte original devido a uma regressão. Ela não deve ser considerada como uma segunda correção necessária para o GhostLock.

Como se trata de uma pequena alteração isolada no caminho de bloqueio, sem alterações no layout de nenhuma estrutura de dados, ela é uma boa candidata a patch que não requer reinicialização em todas as famílias de kernel.

Quem é afetado

O GhostLock afeta sistemas Linux compilados com CONFIG_FUTEX_PI=y, que é a configuração padrão de todas as principais distribuições. O código vulnerável foi introduzido no commit 8161239a8bcc no Linux 2.6.39-rc1 (maio de 2011), e o intervalo vulnerável se estende até a versão v7.1-rc1. Na prática, o impacto é praticamente universal: qualquer kernel nesse intervalo compilado com futex PI.

Vulnerabilidades confirmadas, gatilho e DoS local reproduzidos pela equipe da KernelCare com o PoC público:

• Debian 13 (já corrigido, veja abaixo)
• Debian 12, vulnerável e ainda sem correção
• Debian 11, vulnerável e ainda sem errata
• Enterprise Linux 7, falha de serviço (DoS) reproduzida
• Enterprise Linux 10: falha de serviço (DoS) reproduzida

Privilégios de root em toda a cadeia: o pesquisador demonstrou publicamente a obtenção de privilégios de root com cerca de 97% de confiabilidade. O componente de exploração utilizado como arma é específico para cada alvo, contendo deslocamentos de memória por alvo incorporados em seu código-fonte. Nossa verificação entre distribuições testou o gatilho e a vulnerabilidade “use-after-free”, mas não a obtenção de privilégios de root por alvo em cada distribuição. A suposição segura é que qualquer kernel afetado pode ser explorado para obter privilégios de root por um invasor motivado, e não apenas sujeito a um ataque DoS.

A situação do Enterprise Linux precisa de atenção. Em 8 de julho, a página pública de CVEs da Red Hat listava todos os kernels do RHEL (6, 7, 8, 9 e 10, incluindo o de tempo real kernel-rt) como “Afetado”, com gravidade da ameaça classificada como “Importante”, sem que nenhuma errata tenha sido divulgada até o momento. Essa página sofreu alterações ao longo do dia: no início do dia 8 de julho, ela indicava que o RHEL não estava vulnerável, e qualquer interpretação inicial de que “o EL não foi afetado” se baseava nessa versão, agora substituída. Este é um caso em que ler o comunicado uma única vez e seguir em frente teria levado a uma conclusão errada.

A correção técnica da Red Hat já foi incorporada discretamente ao CentOS Stream (a versão de pré-visualização contínua dos próximos kernels do RHEL). O Stream 9 foi corrigido em kernel-5.14.0-716.el9 e estava vulnerável em kernel-5.14.0-699.el9. O stream 10 foi corrigido em kernel-6.12.0-239.el10 e estava vulnerável em kernel-6.12.0-224.el10. Como o CloudLinux 9 e 10 seguem os kernels do AlmaLinux e do EL9/EL10, essa correção do Stream se aplica a essas versões; portanto, o que você precisa fazer é verificar em qual lado da linha divisória entre o kernel corrigido e o vulnerável se encontra o kernel geral que você está utilizando atualmente. Os limites para o EL7 e o EL8 ainda não foram confirmados.

Aja agora para mitigar

Vamos ser diretos: não existe uma medida de mitigação de tempo de execução clara, geral e válida para todo o host.

O único pré-requisito para o bug é CONFIG_FUTEX_PI, e essa é uma opção definida na compilação, sem opção de ativação em tempo de execução. Ela é necessária para os mutexes de herança de prioridade da glibc; portanto, não pode ser desativada em um kernel de produção em execução sem causar falhas nos programas do espaço do usuário que dependem desses bloqueios. Não há nenhum módulo para colocar na lista negra nem nenhuma configuração para alterar.

Isso nos deixa com as atualizações de patch e uma medida específica para cada carga de trabalho.

Contêineres e cargas de trabalho em ambiente isolado. Uma política de seccomp (o recurso do Linux que filtra quais chamadas de sistema um programa pode realizar) que bloqueia as operações de herança de prioridade do futex, FUTEX_LOCK_PI, FUTEX_WAIT_REQUEUE_PI, e FUTEX_CMP_REQUEUE_PI, fecha o gatilho. Um filtro robusto precisa abranger também as variantes, o futex_time64 chamadas de sistema e números de chamadas de sistema específicos da arquitetura, além de FUTEX_LOCK_PI2 em kernels mais recentes, ou o bloqueio pode ser contornado. O custo é que isso interrompe qualquer carga de trabalho que utilize mutexes com herança de prioridade; portanto, teste antes de implantar. Essa alavanca também é o que torna real o cenário de “fuga do contêiner”: código sem privilégios dentro de um contêiner chega ao bug, a menos que o ambiente de execução já filtre essas operações de futex.

Em todos os outros casos. Não há nenhuma medida de mitigação válida para todo o host, a não ser a aplicação da atualização do kernel fornecida pelo fabricante ou do patch KernelCare, que não requer reinicialização.

Momento decisivo. Se você utiliza contêineres ou sandboxes e pode tolerar a perda dos bloqueios de herança de prioridade, implemente o filtro seccomp como uma medida provisória enquanto planeja a correção definitiva. Para hosts de uso geral, a única solução viável é um kernel corrigido ou um patch que não exija reinicialização; portanto, coloque essas ações no topo da fila e isole a execução local não confiável até que uma dessas soluções seja implementada. Priorize as atualizações já disponíveis do Debian 13 e do EL9, juntamente com as compilações especiais do Ubuntu 24.04, do Proxmox VE 8 e do AlmaLinux, e utilize o repositório de testes quando apropriado para o Debian 12 e o EL10, enquanto a promoção deles para o repositório de produção estiver pendente.

Lista de verificação de medidas corretivas priorizadas

1. Registre isso como CVE-2026-43499 (GhostLock) e confirme se o kernel em execução ou o patchlivepatch sem reinicialização inclui a correção principal, 3bfdc63936dd. A alteração subsequente registrada como CVE-2026-53166 foi revertida no upstream e não é necessária para confirmar a cobertura do GhostLock.
2. Trate cada kernel do intervalo de 2.6.39-rc1 a 7.1-rc1 compilado com CONFIG_FUTEX_PI considerado afetado até que se prove o contrário.
3. Priorize os hosts nos quais o isolamento local constitui a barreira de segurança: hospedagem compartilhada, nós multilocatários, executores de CI e hosts de contêineres e de desenvolvedores que executam código não confiável.
4. No caso do Enterprise Linux, verifique em qual lado da linha divisória entre kernel corrigido e vulnerável cada host se encontra, em vez de confiar apenas na leitura de um único comunicado. Stream 9 corrigido em kernel-5.14.0-716.el9, o Stream 10 fixado em kernel-6.12.0-239.el10; os limites das zonas EL7 e EL8 ainda não foram confirmados.
5. Caso não seja possível aplicar o patch imediatamente e a carga de trabalho permita, aplique um filtro seccomp que bloqueie as operações de herança de prioridade do futex em contêineres e sandboxes.
6. Não desative CONFIG_FUTEX_PI em um kernel em execução; isso corrompe os mutexes de herança de prioridade da glibc e não é uma medida de mitigação suportada.
7. Aplique agora as correções disponíveis para as versões especiais do Debian 13, EL9, Ubuntu 24.04, Proxmox VE 8 e AlmaLinux e utilize o repositório de testes para o Debian 12 e o EL10, enquanto continua acompanhando o Debian 11, o Amazon Linux 2023 e o EL7 à medida que as correções forem disponibilizadas.
8. Busca por core_pattern alterações, avisos do kernel relacionados ao rtmutex-path e ganhos inexplicáveis de privilégios, além de considerar que hashes de arquivos válidos não constituem evidência suficiente sobre o host.
9. Aplique um kernel fixo do fornecedor e reinicie o sistema, ou utilize o patch KernelCare sem reinicialização para o kernel específico que está em execução, priorizando os hosts mais difíceis de reiniciar.

Detecção

O GhostLock não deixa nenhuma assinatura confiável no disco. A corrupção ocorre na memória do kernel, e a ação final documentada altera uma configuração do kernel em vez de modificar arquivos; assim, as ferramentas de integridade de arquivos podem permanecer intactas após a exploração. Isso faz com que a detecção passe a depender da análise comportamental. Os sinais a seguir são derivados da cadeia de exploração publicada, e cada um deles é uma pista, não uma prova:

• Mudanças inesperadas em /proc/sys/kernel/core_pattern, ou às suas permissões, especialmente um manipulador que executa um programa externo em caso de falha. A cadeia pública acaba abusando de core_pattern para obter acesso como root.
• Processos sem privilégios que executam loops curtos de operações de herança de prioridade futex (FUTEX_LOCK_PI, FUTEX_WAIT_REQUEUE_PI, FUTEX_CMP_REQUEUE_PI) em várias threads, de forma consistente com a indução do caminho de impasse.
• Erros ou avisos do kernel no código do rtmutex (mutex em tempo real), por volta de remove_waiter(), rt_mutex_start_proxy_lock(), ou rt_mutex_adjust_prio_chain(), sem nenhuma falha de hardware correspondente.
• Uso de PR_SET_MM_MAP por processos que não têm motivo legítimo para reescrever seu próprio layout de memória, em um intervalo de tempo próximo ao mencionado acima.
• Uma conta ou serviço local que obtém privilégios logo após uma onda de instabilidade nos futex e rtmutex, sem que haja um evento correspondente de sudo ou login.

Verificar as mensagens recentes do kernel:

journalctl -k --since "24 hours ago" | grep -Ei 'rtmutex|pi_blocked|remove_waiter|BUG|WARNING'

A ausência dessas mensagens não comprova que um host esteja atualizado ou não tenha sido comprometido. Um invasor astuto pode evitar acionar um alerta, e uma vulnerabilidade pode simplesmente ainda não ter sido explorada. Se algum código local não confiável ou parcialmente confiável tiver sido executado em um host afetado durante o período de exposição, considere que o host merece uma análise mais detalhada — incluindo novas contas, alterações na configuração de autenticação e serviços inesperados —, em vez de interpretar hashes de arquivos válidos como prova de segurança.

Por que o GhostLock é importante

O GhostLock é uma escalação de privilégios local, não uma execução remota de código. Ninguém consegue obter acesso root no seu servidor pela internet apenas com isso. Para os ambientes em que ele realmente se instala, isso é um consolo insignificante.

A hospedagem compartilhada executa o código dos clientes. Os executores de CI executam o que quer que a última solicitação de pull tenha determinado. Os contêineres e os nós do Kubernetes executam cargas de trabalho em diferentes níveis de confiança, e os hosts multilocatários existem especificamente para manter os locatários separados. Em cada um desses casos, a escalada de privilégios local é o evento que todo o projeto se destina a impedir. Ela transforma código que tinha permissão para ser executado em código executado como root, onde nunca deveria ter sido.

A razão pela qual é fácil avaliar mal a situação é a mesma pela qual ela é perigosa. Três sinais plausíveis apontam para “seguro” e todos induzem ao erro. A idade da falha parece algo digno de um museu, quando, na verdade, ela ainda pode ser explorada em um kernel padrão hoje em dia. O recurso futex parece algo de nicho, quando, na verdade, está compilado em praticamente todas as distribuições e é usado pelos bloqueios padrão da glibc. E um comunicado verificado uma vez na manhã de 8 de julho poderia ter indicado que o RHEL não estava vulnerável, horas antes de a mesma página ser atualizada para listar todos os kernels do RHEL como afetados. Confie em qualquer um desses sinais e você classificará um host vulnerável como seguro.

O GhostLock é exatamente o tipo de bug para o qual existem correções sem reinicialização. A alteração do desenvolvedor original está disponível, mas isso não protege um sistema em execução: o fornecedor precisa fazer o backport, você precisa instalar o pacote e a máquina precisa inicializar com o novo kernel. Em ambientes com múltiplos usuários e em frotas de contêineres, essa última etapa pode prolongar a exposição residual a um bug conhecido de acesso root local por semanas, e o impacto é maior justamente nos hosts que correm maior risco.

Essa alteração é uma boa candidata a um patch que não requer reinicialização: uma correção pequena e independente no caminho de bloqueio, sem alteração no layout da estrutura de dados e sem estado persistente a ser transferido. O KernelCare porta a correção principal do GhostLock, 3bfdc63936dd, para o kernel em execução. Observação: trata-se de um bug exclusivo do kernel, sem nenhum componente de biblioteca no espaço do usuário.

Situação do lançamento dos patches em tempo real (KernelCare) em 10 de julho de 2026, às 17h UTC.

Feed principal:

• Família EL9: RHEL 9, AlmaLinux 9, Oracle Linux 9, Rocky Linux 9
• AlmaLinux 9 LTS e AlmaLinux 9 FIPS 9.6
• Ubuntu 24.04
• Proxmox VE 8

Feed de teste:

• Família EL10: RHEL 10, AlmaLinux 10, Rocky Linux 10, Oracle Linux 10
• Debian 12

Corrigido pelo fornecedor e lançado:

• Debian 13

Em espera ou ainda não lançado:

• Amazon Linux 2023: já está pronta, mas ainda não foi lançada
• Debian 11: cobertura pendente
• EL7: cobertura pendente
• EL6: baixa prioridade

As informações sobre o patch do KernelCare referem-se apenas ao CVE-2026-43499; a constatação desse CVE confirma que o GhostLock foi corrigido. A alteração subsequente, registrada como CVE-2026-53166, foi revertida no código-fonte devido a uma regressão e não é necessária para verificar a cobertura.

Inscreva-se pelo feed de testes assim que uma K-tag estiver disponível:

kcarectl --update --prefix test

Aplique a partir do feed de produção assim que for promovido:

kcarectl --update

Confirme o mapeamento do GhostLock para o CVE, em vez de confiar na data de compilação:

kcarectl --info | grep kpatch-build-time      # build dated 2026-07-08 or later
kcarectl --patch-info | grep 'CVE-2026-43499'

A data de compilação, por si só, não prova nada, pois um kernel compilado após meados de abril não inclui automaticamente a correção do GhostLock. Verifique diretamente o mapeamento do CVE, a errata do fornecedor, o código-fonte ou o status do patch sem reinicialização.

O GhostLock transforma um erro de bloqueio de quinze anos em uma falha na barreira de privilégios locais. Para frotas que não podem arcar com reinicializações de emergência, um patch que não requer reinicialização fecha essa barreira no kernel em execução, sem sobrecarregar os nós nem interromper as cargas de trabalho.

Adquira o KernelCare hoje mesmo →

Linha do tempo

Referências

• IonStack – Parte II: GhostLock, Nebula Security, 07/07/2026: https://nebusec.ai/research/ionstack-part-2/
• Entrada na lista de bugs, CVE-2026-43499: https://nebusec.ai/buglist/CVE-2026-43499
• Demonstração pública de conceito (PoC), CyberMeowfia/IonStack/CVE-2026-43499: https://github.com/NebuSec/CyberMeowfia/tree/main/IonStack/CVE-2026-43499
• Correção na fase inicial 3bfdc63936dd (“rtmutex: Use waiter::task em vez de current em remove_waiter()”): https://git.kernel.org/linus/3bfdc63936dd4773109b7b8c280c0f3b5ae7d349
• Revertida a alteração de acompanhamento 74e144274af3 (CVE-2026-53166; posteriormente revertida no código-fonte original devido a uma regressão): https://git.kernel.org/linus/74e144274af39935b0f410c0ee4d2b91c3730414
• Commit que introduziu um bug 8161239a8bcc (“rtmutex: Simplificar o algoritmo PI e fazer com que a tarefa de maior prioridade obtenha o bloqueio”), contido na versão v2.6.39-rc1
• Red Hat CVE-2026-43499 (kernel do RHEL 6-10 / kernel-rt listados como afetados, gravidade: Importante, BZ 2480453): https://access.redhat.com/security/cve/cve-2026-43499
• Correções silenciosas do CentOS Stream: cs9 4e5a31ae1fa9, cs10 7bba8926cefe
• Imprensa: The Hacker News, “Falha no GhostLock, com 15 anos, permite acesso root…”: https://thehackernews.com/2026/07/15-year-old-ghostlock-flaw-enables-root.html