CVE-2022-0185
Prioriza la corrección. Ella está bajo explotación confirmada por CISA y tiene prueba de concepto pública.
Apply updates per vendor instructions or discontinue use of the product if updates are unavailable.
Resumen
Falha de integer overflow (CWE-190) na função legacy_parse_param() do subsistema Filesystem Context do kernel Linux, que permite escrita fora dos limites de um buffer alocado no heap. Um usuário local com CAP_SYS_ADMIN no namespace atual — obtenível sem privilégios especiais em sistemas com user namespaces sem restrição — pode escalar para root. Está no catálogo KEV da CISA com exploração confirmada e há PoCs públicos funcionais, incluindo escape de container.
Detalle técnico
O bug está em fs/fs_context.c, na função legacy_parse_param(), usada quando um filesystem não implementa a API moderna de Filesystem Context e cai no tratamento legado de parâmetros de montagem. A verificação de limite era `if (len > PAGE_SIZE - 2 - size)`, onde size e len são valores unsigned. Quando size chega a 4095 ou mais, a subtração `PAGE_SIZE - 2 - size` sofre underflow e vira um número positivo enorme em vez de negativo, fazendo a checagem nunca disparar. A partir daí o código copia dados do usuário para além do buffer de uma página (slab) alocado para acumular os parâmetros, resultando em heap overflow controlado pelo atacante em tamanho e, em certa medida, em conteúdo.
O bug foi introduzido no commit 3e1aeb00e6d1, no ciclo 5.1-rc1, quando o parsing legado de parâmetros foi reescrito, e permaneceu presente em todas as releases subsequentes até a correção. O atacante controla o valor cumulativo de 'size' (soma de opções de montagem já processadas) e o 'len' da opção atual — manipulando a sequência e o tamanho das opções passadas via mount(), ele decide onde e quanto escreve fora dos limites do buffer.
A correção (commit 722d94847de29310e8aa03fcbdb41fc92c521756, mesclada em 18/01/2022) elimina a subtração problemática e passa a verificar `if (size + len + 2 > PAGE_SIZE)`, evitando o underflow.
Cómo se explota
A exploração exige que o processo tenha CAP_SYS_ADMIN no namespace em que atua — não necessariamente na hierarquia raiz. Se o kernel permite user namespaces sem privilégio (unprivileged user namespaces, configuração comum em distribuições desktop e em muitos containers), um usuário sem nenhum privilégio pode criar um novo namespace de usuário e de mount via unshare(CLONE_NEWNS|CLONE_NEWUSER) e, dentro dele, ganhar CAP_SYS_ADMIN efetivo. A partir daí, basta montar um filesystem que não implemente a API moderna de Filesystem Context (cai no caminho legado) e fornecer opções de montagem manipuladas para acionar o overflow.
Exploits públicos documentados (repositório Crusaders-of-Rust) demonstram duas rotas: uma usando objetos elásticos do FUSE e do SYSVIPC para conseguir escrita arbitrária, testada contra Ubuntu 20.04 (kernel 5.11.0-44) e adaptável a kernels 5.7+; e outra, visando infraestrutura kCTF do Google (GKE 1.22.3-gke.700), que usa pipes e SYSVIPC para provocar um stack pivot e executar uma ROP chain em espaço de kernel, alcançando RCE como root no namespace raiz com confiabilidade de até 50%. Isso configura escape de container em ambientes onde o container tem CAP_SYS_ADMIN no seu namespace.
A CISA confirma exploração ativa (entrada no KEV desde 21/08/2024, com prazo de mitigação em 11/09/2024), embora a data de inclusão seja bem posterior à divulgação original — a vulnerabilidade circula há anos com PoCs maduros e continua relevante em sistemas não corrigidos, especialmente ambientes multi-tenant com user namespaces habilitados.
Versiones
Cómo protegerse
Aplicar o patch do kernel que corrige legacy_parse_param() (commit 722d94847de29310e8aa03fcbdb41fc92c521756, integrado em 18/01/2022) ou atualizar para uma versão de kernel/distribuição que já incorpore esse backport. As distribuições fizeram backport para seus ramos LTS/estáveis logo após a divulgação; confirme a presença do commit no changelog do kernel específico da sua distro em vez de assumir por número de versão.
Como paliativo quando não é possível atualizar imediatamente: restringir ou desabilitar unprivileged user namespaces (por exemplo via sysctl kernel.unprivileged_userns_clone=0, onde disponível) reduz drasticamente a superfície, pois a maior parte das explorações depende de obter CAP_SYS_ADMIN sem privilégio prévio por essa via. Isso tem custo — quebra funcionalidades que dependem de namespaces sem privilégio (alguns runtimes de container, sandboxes de navegador). Restringir CAP_SYS_ADMIN via políticas de seccomp/AppArmor/SELinux em containers também reduz a exposição, mas não elimina o vetor para usuários locais com acesso root de namespace legítimo.
Não funciona como mitigação: confiar apenas em isolamento de container sem restringir capabilities, já que o próprio PoC documentado demonstra escape de container explorando exatamente esse cenário. Monitoramento de aplicação também não substitui o patch — a falha é no kernel, abaixo de qualquer controle de aplicação.
Cómo detectar
Não há assinatura de log de aplicação confiável: a exploração ocorre inteiramente em espaço de kernel via syscalls de mount/unshare, sem gerar entradas padrão em logs de aplicação. Como indício, auditoria de syscalls (auditd/eBPF) pode registrar chamadas a unshare() com CLONE_NEWUSER|CLONE_NEWNS seguidas de tentativas de mount de filesystems legados por usuários sem privilégio elevado — um padrão anômalo em hosts onde isso não é esperado. Kernel panics ou crashes inexplicados em fs_context.c/legacy_parse_param em dmesg após tentativas de mount malformadas também podem indicar tentativa de exploração falha, mas isso não é um sinal sistemático nem documentado oficialmente como IOC.