Suporte Técnico
Documentação
Entrar
Entre em contato conosco
Vá direto para um resumo gerado por IA desta postagem do blog 
28 de maio de 2026 – 7 minutos de leitura Chris DeMars, Advogado Sênior de Desenvolvedores
A versão resumida
O que é: Uma nova vulnerabilidade de escalonamento de privilégios locais no Linux, denominada CIFSwitch, explora a ausência de uma verificação no kernel sobre as descrições das chaves cifs.spnego, combinada com a confiança que o auxiliar cifs.upcall do espaço do usuário deposita nessas descrições. O resultado é a obtenção de um shell com privilégios de root a partir de qualquer conta local sem privilégios nos hosts afetados. A falha no código do kernel está presente desde 2007. Nenhum CVE havia sido atribuído até o momento da publicação.
Impacto: Uma demonstração pública de conceito, de autoria de Asim Manizada, oferece a qualquer usuário local sem privilégios um caminho confiável para obter privilégios de root em sistemas que atendam aos pré-requisitos da vulnerabilidade. O autor confirmou a vulnerabilidade em cerca de 30 combinações de distribuições e edições.
Status: Manizada divulgou o CIFSwitch no oss-security em 28 de maio de 2026, após um período de embargo na lista linux-distros. A falha foi relatada aos mantenedores do kernel/cifs em 16 de maio, e a correção do upstream (commit 3da1fdf4efbc) já está disponível ao público há mais de uma semana e está na fila para a versão estável.
Gravidade: Confirmada por padrão no AlmaLinux 9.7, Rocky Linux 9 Workstation, CentOS Stream 9 GNOME, Linux Mint 21/22, Kali 2021 a 2026 (sem interface gráfica) e SLES 15 SP7/SAP. Vulnerável quando o cifs-utils é instalado manualmente no Debian 11/12/13, Ubuntu 18/20/22/24.04, openSUSE Leap 15.6, Oracle Linux 8/9 e Amazon Linux 2023.
Por que isso é importante: A vulnerabilidade tem como alvo um utilitário privilegiado instalado por padrão, requer apenas um shell local sem privilégios e possui um PoC público funcional. Qualquer host Linux no qual um invasor sem privilégios possa executar código deve ser considerado em risco imediato se o pacote cifs-utils e a regra padrão cifs.spnego estiverem presentes, o módulo do kernel CIFS estiver disponível, os namespaces sem privilégios estiverem habilitados e a política do LSM não bloquear a transição de privilégios.
Faça isso agora: se o seu host não montar compartilhamentos SMB autenticados por Kerberos (a maioria dos servidores não o faz), substitua ou remova a regra padrão de chave de solicitação `cifs.spnego`. Se você não precisar de contêineres sem privilégios de root ou do recurso `unprivileged unshare`, desative os namespaces de usuários sem privilégios. Os comandos e as vantagens e desvantagens estão abaixo.
Não quer ter que agendar uma sexta reinicialização de emergência seguida? O KernelCare aplica patches no kernel do Linux sem tempo de inatividade nem interrupções.
Atualização (22/05/2026, 14h UTC): As correções sem reinicialização estão sendo distribuídas do canal de testes para o canal principal. Consulte a seção “Correções sem reinicialização” abaixo para saber o status atual. Continuaremos atualizando esta publicação à medida que as correções forem implementadas.
A versão completa
Asim Manizada divulgou o CIFSwitch na lista de discussão oss-security em 28 de maio de 2026, dia em que expirou o embargo acordado com as distribuições Linux. O relatório original foi enviado aos mantenedores do kernel em 16 de maio. A correção do upstream já está disponível ao público há mais de uma semana e está agendada para a versão estável. As distribuições downstream ainda estão incorporando a correção.
A falha no kernel remonta ao commit f1d662a, de 2007, que adicionou o tipo de chave cifs.spnego sem um gancho de validação de descrição. A falha permaneceu latente por 19 anos porque a cadeia de exploração prática depende de duas adições posteriores: os namespaces de usuários sem privilégios no Linux v3.8 (2013) e a lógica de troca de namespace no cifs-utils (nominalmente, isso se aplica à versão 6.14 e superiores, mas backports de outras correções de CVE também introduziram problemas em versões mais antigas do cifs-utils). Sem todas as três partes reunidas, a cadeia não funciona do início ao fim.
Manizada é franco em seu artigo ao afirmar que a falha foi identificada por meio de raciocínio em grafos assistido por LLM sobre objetos do kernel, propriedades de segurança e os limites onde esses objetos se cruzam entre o kernel e o espaço do usuário. A técnica de descoberta é interessante por si só. Por enquanto, a questão mais urgente é o que a falha faz e como impedi-la.
Como funciona a vulnerabilidade
A vulnerabilidade envolve quatro componentes: um recurso do kernel do Linux chamado “keyrings”, um auxiliar do espaço do usuário chamado “cifs.upcall”, os namespaces do usuário do Linux e o Name Service Switch (NSS). Cada um desses componentes é parte da infraestrutura normal, desempenhando sua função. O problema é que nunca foi imposta uma barreira de confiança entre o kernel e o espaço do usuário, e o restante da cadeia decorre disso.
Etapa 1: chaveiros do kernel e o tipo de chave cifs.spnego
Os chaveiros do Linux são um subsistema do kernel que armazena materiais de autenticação, como tickets do Kerberos e chaves de criptografia. Quando o kernel precisa de uma chave que não possui, ele solicita ao espaço do usuário que gere uma por meio de um mecanismo de chamada externa. Uma regra no arquivo /etc/request-key.d/ determina que “para gerar uma chave desse tipo, execute este programa auxiliar como root”. Para montagens SMB ou CIFS que utilizam Kerberos, o tipo de chave é cifs.spnego e o programa auxiliar padrão é o /usr/sbin/cifs.upcall, fornecido no pacote cifs-utils.
Quando o kernel solicita uma chave cifs.spnego, ele gera uma string descritiva que contém campos de autorização: o ID do usuário para a montagem, o UID da credencial, o ID do processo e o namespace de destino. Essa string deve ser fornecida pelo kernel. O auxiliar do espaço do usuário confia nesses campos e os utiliza para decidir quais credenciais consultar e em qual namespace agir.
Etapa 2: verificação do kernel ausente
O espaço do usuário pode chamar diretamente a chamada de sistema request_key() e solicitar uma chave cifs.spnego com qualquer descrição que desejar. Antes do patch, faltava na definição cifs_spnego_key_type do kernel o gancho .vet_description, que instrui o subsistema de chaveiro a “aceitar apenas descrições de uma origem específica”. Sem esse gancho, qualquer processo sem privilégios pode solicitar uma chave cifs.spnego com uma descrição falsificada, e o chaveiro inicia o cifs.upcall como root com a descrição do invasor em mãos.
Um detalhe que vale a pena destacar logo de início, a partir do artigo de Manizada: o kernel não precisa, na verdade, retornar uma chave para que o `cifs.upcall` seja executado. O helper é executado primeiro. Quando o kernel rejeita a chave como inválida, o helper de raiz já fez o que o invasor queria. É isso que torna a falta do gancho de validação mencionado acima tão grave.
Etapa 3: troca de namespace dentro do helper raiz
cifs.upcall parses the description, finds upcall_target=app and pid=<some-pid>, and calls setns() to switch into the namespaces of the supplied pid. This is a deliberate feature, intended to make cifs.upcall resolve names against the right filesystem and network view when serving containerized mounts. The problem is that the kernel has just been tricked into trusting an attacker’s pid as if it came from a real kernel-side CIFS operation.
Etapa 4: O NSS como primitiva de carregamento de código
Antes de obter privilégios de root, o cifs.upcall realiza uma consulta de conta com a função getpwuid(). No Linux, as consultas de conta passam pelo Name Service Switch (NSS), um sistema plugável configurado no arquivo /etc/nsswitch.conf que determina quais bibliotecas compartilhadas devem ser carregadas para cada tipo de consulta. Agora que o cifs.upcall está dentro do namespace de montagem do invasor, o arquivo nsswitch.conf que ele lê é o do invasor, e o módulo NSS que ele carrega é um libnss_*.so.2 controlado pelo invasor. Esse objeto compartilhado é executado como root dentro do helper.
Etapa 5: persistência via sudo
O módulo NSS da demonstração pública (PoC) grava um arquivo na pasta /etc/sudoers.d/, concedendo ao invasor o direito NOPASSWD: ALL. Após o encerramento do processo auxiliar, o invasor sai do namespace e executa o comando `sudo`. O shell é executado como root. O binário do cifs.upcall armazenado no disco permanece intacto; a exploração ocorre no processo auxiliar em execução e no namespace controlado pelo invasor.
A correção é pequena. O patch do upstream adiciona uma função cifs_spnego_key_vet_description() de quatro linhas que compara current_cred() com o spnego_cred privado do kernel. Se não houver correspondência, a solicitação de chave é rejeitada com o código de erro -EPERM. Apenas o próprio caminho de código CIFS do kernel tem permissão para instanciar uma chave desse tipo. Isso é suficiente para interromper a cadeia na etapa 2.
Quem é afetado
O caminho de código vulnerável do cifs.spnego remonta a 2007, mas a cadeia de exploração pública só é praticamente acessível em sistemas com suporte a namespaces de usuário sem privilégios da era do Linux v3.8 e com os demais pré-requisitos atendidos. O funcionamento da cadeia de exploração em um determinado host depende de três condições subsequentes: se o cifs-utils está instalado, se os namespaces de usuários sem privilégios estão habilitados e se a política LSM do host (SELinux ou AppArmor) bloqueia alguma etapa da cadeia.
Pronto para uso imediato (cifs-utils pré-instalado, namespaces sem privilégios ativados, a política padrão do LSM permite a cadeia): AlmaLinux 9.7 Workstation e a imagem na nuvem do Azure, Rocky Linux 9 Workstation, CentOS Stream 9 GNOME, Linux Mint Cinnamon 21.3 e 22.3, Kali Linux 2021.4 a 2026.1 (sem interface gráfica), SLES 15 SP7, SLES SAP 15 SP7 e SLES SAP 16.
Isso também foi confirmado internamente pela KernelCare no CloudLinux 10. O CL é fornecido com o SELinux desativado por meio de seus perfis do `tuned`, portanto, a configuração específica do SELinux que protege o RHEL 10, o AlmaLinux 10, o Rocky Linux 10 e o Oracle Linux 10 não se aplica ao CloudLinux 10.
Vulnerável se o cifs-utils for instalado manualmente: Ubuntu 18.04, 20.04, 22.04 e 24.04 (versões Desktop e Server); a versão 24.04 requer, além disso, o truque “aa-exec -p trinity”, documentado publicamente, para contornar a política de usuários do AppArmor; Pop!_OS 22.04 e 24.04; Debian 11, 12 e 13; CentOS Stream 9 Cinnamon/KDE/MATE/XFCE; Rocky Linux 9 KDE e Workstation-Lite; openSUSE Leap 15.6; Rocky Linux 8 GenericCloud; Oracle Linux 8 e 9 KVM; Amazon Linux 2023 KVM.
Bloqueado pela política padrão, mas vulnerável por baixo: a maioria das distribuições EL10 (RHEL 10, AlmaLinux 10, Rocky Linux 10, Oracle Linux 10) bloqueia o pivô do namespace cifs.upcall no modo de aplicação do SELinux. O Ubuntu 26.04 bloqueia a cadeia sob sua política padrão do AppArmor para usuários. O Fedora 40 a 44 e o CentOS Stream 10 também bloqueiam por padrão. Esses hosts tornam-se vulneráveis a explorações se o operador executar o comando `setenforce 0` ou flexibilizar os parâmetros sysctl do AppArmor para usuários.
Não explorável pelo público (PoC): Amazon Linux 2, que vem com o cifs-utils 6.2 e é anterior à lógica de troca de namespace. CentOS 7 e RHEL 7, que têm user.max_user_namespaces = 0 por padrão. Kali Linux 2019.4 e 2020.4 com a versão mais antiga do cifs-utils 6.9.
A exposição depende, em última instância, de três fatores: se o cifs.upcall está disponível, se usuários sem privilégios são permitidos e se a política do LSM bloqueia a transição de namespace. Verifique esses aspectos com os comandos da próxima seção.
Aja agora para mitigar
A cadeia tem dois pré-requisitos, e cada um deles oferece uma mitigação eficaz. Escolha aquele cujas vantagens e desvantagens se adequem à sua carga de trabalho.
Recomendado: substituir a regra padrão de chave de solicitação do cifs.spnego
Se o servidor não montar compartilhamentos SMB autenticados por Kerberos (a maioria dos servidores não o faz), a regra padrão de chave de solicitação cifs.spnego não será utilizada. Substituí-la interrompe a cadeia na etapa 1. As montagens de clientes SMB baseadas em NTLM/senha geralmente não dependem da chamada de retorno SPNEGO do Kerberos, mas verifique suas opções de montagem antes de remover a regra.
echo 'create cifs.spnego * * /usr/sbin/keyctl negate %k 30 %S' | sudo tee /etc/request-key.d/cifs.spnego.confAjuste o caminho do `keyctl` caso sua distribuição o tenha instalado em outro local. Isso corresponde à substituição recomendada pelo autor e rejeita a solicitação de chave de forma limpa, em vez de gerar uma falha por meio de um binário que não pertença ao keyring.
Se você não usa o SMB de forma alguma, remova o arquivo completamente:
sudo rm /etc/request-key.d/cifs.spnego.confNão aplique isso em hosts que montam compartilhamentos SMB autenticados por Kerberos. O `cifs.upcall` é exatamente o auxiliar de tickets SPNEGO do qual essas montagens dependem.
Após a aplicação do patch, reverte a alteração reinstalando o cifs-utils (o que restaura a regra padrão) ou removendo seu arquivo de substituição.
Alternativa: desativar os espaços de nomes de usuários sem privilégios
O PoC deve inserir um usuário privado e um namespace de montagem antes de acionar a chamada ascendente. Bloquear usuários sem privilégios interrompe a cadeia, independentemente do estado do cifs-utils.
# EL family:
sudo sysctl -w user.max_user_namespaces=0
echo 'user.max_user_namespaces = 0' | sudo tee /etc/sysctl.d/99-cifswitch.conf
# Debian / Ubuntu:
sudo sysctl -w kernel.unprivileged_userns_clone=0
echo 'kernel.unprivileged_userns_clone = 0' | sudo tee /etc/sysctl.d/99-cifswitch.confNota de compatibilidade: os espaços de nome de usuário sem privilégios são exigidos por ambientes de execução de contêineres sem root (Podman sem root, Docker sem root, Flatpaks baseados em bwrap), várias sandboxes de CI, o comando unshare(1) sem privilégios e a sandbox do Chromium. Aceitável em cargas de trabalho de hospedagem, mas prejudicial em hosts de desenvolvedores ou de contêineres.
Outra opção: desinstalar o cifs-utils nos casos em que o cliente SMB não for utilizado
A maioria das frotas de servidores não precisa disso. Ao remover o pacote, o cifs.upcall e a regra padrão de chave de solicitação são removidos juntos.
# Debian / Ubuntu
sudo apt remove cifs-utils
# RHEL / AlmaLinux / Rocky / Oracle / CentOS Stream
sudo dnf remove cifs-utilsVerifique se o seu servidor está exposto
# Is cifs-utils installed?
command -v cifs.upcall && (rpm -q cifs-utils 2>/dev/null || dpkg -l cifs-utils 2>/dev/null)
# Is the default cifs.spnego request-key rule present?
cat /etc/request-key.d/cifs.spnego.conf 2>/dev/null
# Are unprivileged user namespaces enabled?
sysctl user.max_user_namespaces kernel.unprivileged_userns_clone 2>/dev/nullUm host só é um alvo viável se o cifs.upcall estiver instalado, se houver uma regra de chave de solicitação cifs.spnego e se o acesso de usuários sem privilégios for permitido.
Patch KernelCare sem reinicialização
Situação em 29/05/2026, às 14h00 UTC: os patches sem reinicialização para o EL8 foram implantados no canal principal. Os patches para o AlmaLinux 9 também foram implantados no canal principal. Os patches sem reinicialização para as demais variantes do EL9, EL10, kernels UEK do Oracle Linux (UEK6 e UEK7), Ubuntu, Debian e Proxmox VE foram implantados no canal de teste.
Assim que estiver disponível no feed de teste, siga as instruções abaixo para se inscrever:
kcarectl --update --prefix testApós a validação, o patch é incluído na próxima execução programada ou pode ser baixado sob demanda:
kcarectl --updateVerifique se o patch foi aplicado. O patch é fornecido sem um ID CVE e pode ser identificado por meio de sua descrição no código-fonte original:
kcarectl --patch-info | grep 'cifs.spnego'
# expected: kpatch-description: smb: client: reject userspace cifs.spnego descriptions (cifs LPE)Assim que um CVE for atribuído, o comando `kcarectl –patch-info | grep CVE-2026-` irá exibi-lo.
O que acompanhar à medida que a situação se desenrola
A atribuição do CVE ainda está pendente. As atualizações do kernel de distribuição da Red Hat, Ubuntu, Debian, SUSE, Oracle e Amazon estão sendo implementadas à medida que os projetos derivados adotam o backport estável que está na fila.
Continuaremos atualizando esta publicação à medida que os patches que não exigem reinicialização forem lançados e à medida que o CVE for atribuído.
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 →
