Falhas em manipuladores `mmap()` do núcleo Linux permitem escalonamento local de privilégio

Erro de validação em driver privilegiado com uso de remap_pfn_range() pode permitir leitura e escrita em memória sensível do núcleo quando um usuário local acessa o dispositivo vulnerável.

Componente	Manipuladores mmap() em drivers do núcleo Linux, com caso concreto no driver udl da DisplayLink por meio das operações fb_helper no subsistema video/drm.
Vetor	Usuário local com acesso a um driver privilegiado vulnerável informa parâmetros controláveis de mapeamento de memória, incluindo deslocamento e tamanho, capazes de acionar estouro inteiro na validação.
Impacto	Leitura e escrita em páginas sensíveis de memória do núcleo, criando uma primitiva que pode levar a execução de código no espaço do núcleo e escalonamento local de privilégio.
Prioridade	Aplicar a correção do núcleo validada, revisar permissões de dispositivos expostos a usuários locais e auditar drivers que implementam mmap() próprio com chamadas a remap_pfn_range().
Versões	A falha foi descrita como presente até a versão 4.16-rc3 do núcleo Linux e introduzida cerca de oito anos antes da análise.
Artefatos	mmap(), remap_pfn_range(), file_operations, fb_helper, udl, DisplayLink e cálculo vulnerável envolvendo offset + size.

Resumo técnico

A vulnerabilidade envolve a forma como determinados drivers do núcleo Linux implementam manipuladores próprios para mmap(). Em vez de reutilizar um caminho comum já amadurecido pelo próprio núcleo, alguns drivers definem lógica local para aceitar uma requisição de mapeamento vinda do espaço de usuário e convertê-la em páginas físicas acessíveis pelo processo chamador. Esse desenho é sensível porque campos controlados pelo usuário, como endereço, tamanho e deslocamento, entram diretamente na decisão sobre qual intervalo de memória será exposto. Quando a validação desses campos é incompleta, o driver pode permitir que uma área fora do buffer legítimo do dispositivo seja mapeada em um processo não privilegiado.

O caso concreto analisado aparece no driver udl, associado a dispositivos DisplayLink, dentro do fluxo de operações fb_helper no subsistema video/drm. A lógica vulnerável usa uma checagem baseada na soma entre deslocamento e tamanho para confirmar se o intervalo solicitado permanece dentro da região de memória esperada. Como o deslocamento é tratado como valor sem sinal, a soma offset + size pode sofrer estouro inteiro e voltar para um valor baixo. Com isso, uma requisição inválida consegue passar por uma condição que deveria barrar acessos fora do intervalo permitido.

O impacto confirmado é local e depende de acesso ao driver privilegiado vulnerável. Nessa condição, o usuário consegue mapear páginas que não deveriam estar disponíveis e operar leitura e escrita sobre memória sensível do núcleo. Essa capacidade não é apenas uma falha de confidencialidade: ela fornece uma primitiva poderosa para alterar estruturas internas e pode ser encadeada para execução de código no espaço do núcleo, resultando em escalonamento local de privilégio. A análise também mostrou que o problema havia permanecido no núcleo por anos, reforçando que interfaces antigas de drivers continuam exigindo revisão mesmo em projetos amplamente auditados.

Fluxo técnico

O ponto crítico está na fronteira entre a chamada mmap() feita por um processo em espaço de usuário e o manipulador implementado pelo driver no núcleo. O usuário controla parâmetros que descrevem o intervalo desejado, incluindo o tamanho da região e o deslocamento usado para selecionar a parte do buffer a ser mapeada. Em um driver correto, a validação precisa garantir que o intervalo comece dentro da região autorizada, que o tamanho seja coerente e que a soma entre início e fim não ultrapasse o limite do buffer interno associado ao dispositivo. Também é necessário considerar estouros aritméticos antes de confiar no resultado de uma soma.

No padrão vulnerável, o driver deixa de validar uma condição inicial porque interpreta o deslocamento como valor sem sinal, e passa a depender de uma comparação posterior envolvendo offset + size. Essa decisão falha quando o deslocamento é escolhido de modo que a soma ultrapasse o limite representável e retorne para um número pequeno. A comparação então enxerga um intervalo aparentemente aceitável, embora o deslocamento original esteja fora do espaço legítimo. Na etapa seguinte, a rotina que efetivamente cria o mapeamento usa esse valor para calcular a página física a ser exposta ao processo.

A função remap_pfn_range() é relevante porque estabelece o vínculo entre páginas físicas e o espaço de endereçamento do processo chamador. Ela não substitui a validação semântica que cabe ao driver: se o driver calcula um intervalo indevido e entrega parâmetros incorretos, a função pode mapear memória que nunca deveria ser alcançável por aquela interface. Em máquinas de 64 bits, a análise considerou ainda a particularidade de que apenas parte do espaço de endereçamento físico é acessível; por isso, um deslocamento extremamente grande precisa também produzir, após o ajuste aritmético, um endereço físico mapeável. Esse detalhe limita a exploração direta, mas não elimina o defeito.

A verificação técnica foi feita com uma máquina virtual Ubuntu de 64 bits e um driver simulado contendo a implementação a ser testada. O teste confirmou que duas chamadas consecutivas de mapeamento conseguiam alcançar uma página física alinhada associada à implementação de /dev/urandom no núcleo. A validação adicional indicou que o processo podia ler e escrever nas páginas mapeadas. Esse resultado demonstra que a falha não se restringe a um desvio de checagem abstrato: ela altera a fronteira real de acesso entre usuário e núcleo.

Superfície afetada

A superfície exposta é formada por sistemas Linux que carregam drivers com manipuladores mmap() próprios e que disponibilizam o dispositivo vulnerável a usuários locais. O caso documentado envolve o driver udl da DisplayLink, mas a técnica de busca identificou que o padrão merecia revisão em outros drivers que chamam remap_pfn_range(). O problema não nasce da existência de mmap() em si; a chamada é legítima e comum para compartilhar buffers entre processos e dispositivos. A falha surge quando a implementação local não replica corretamente as validações de intervalo, tamanho e estouro inteiro.

O requisito de acesso local é importante para delimitar o risco. O cenário descrito não aponta execução remota pela rede, exploração ativa pela internet ou comprometimento automático de hosts sem interação local. O atacante precisa conseguir abrir a interface do driver vulnerável e emitir uma requisição de mapeamento com parâmetros maliciosos. Em estáções compartilhadas, servidores com usuários sem privilégios, ambientes de pesquisa, sistemas multiusuário e cargas de trabalho com dispositivos gráficos ou periféricos expostos, esse requisito ainda pode ser relevante porque a elevação de privilégio quebra o isolamento esperado entre contas locais e o núcleo.

A versão mencionada como afetada chega à árvore 4.16-rc3 do núcleo Linux, e a falha foi descrita como introduzida cerca de oito anos antes da correção. Para defesa, isso significa que a idade do código não deve ser usada como indicador de segurança. Drivers menos revisados, principalmente aqueles que implementam caminhos próprios para operações de arquivo, podem manter erros de fronteira por longos períodos quando não há testes específicos para aritmética de limites e mapeamento de memória.

• Drivers do núcleo Linux que definem operação mmap() em file_operations e fazem mapeamento direto de páginas físicas.
• Driver udl da DisplayLink no caminho fb_helper do subsistema video/drm.
• Sistemas em que usuários locais conseguem acessar o nó de dispositivo associado ao driver vulnerável.
• Ambientes baseados em núcleo até 4.16-rc3 quando ainda não receberam a correção correspondente.

Hunting e telemetria

A detecção deve começar pelo inventário de módulos carregados e pela exposição de dispositivos acessíveis a contas não privilegiadas. Em hosts Linux, o risco operacional aumenta quando um driver vulnerável está presente e o nó de dispositivo permite leitura, escrita ou mapeamento por usuários fora de grupos administrativos estritamente controlados. A telemetria deve correlacionar abertura de dispositivos, chamadas de mapeamento e mudanças incomuns de privilégio no mesmo intervalo temporal. Como a falha é local e atua no limite entre processo e núcleo, os sinais podem ser discretos e aparecer mais claramente como comportamento anômalo posterior, não como uma assinatura de rede.

Equipes de segurança também devem revisar logs de autenticação e auditoria para identificar contas que obtiveram privilégios elevados após interações incomuns com dispositivos gráficos ou periféricos. Em ambientes com auditd ou EDR para Linux, eventos de abertura de arquivos de dispositivo, uso de mmap() em processos inesperados e escrita em regiões mapeadas podem ser usados como sinais auxiliares. A ausência de telemetria específica para páginas físicas não elimina a possibilidade de investigação: a cadeia defensiva deve focar em precondições observáveis, como módulo carregado, permissões permissivas e processos locais com comportamento fora do perfil.

No nível de engenharia, o hunting de código é tão importante quanto o hunting operacional. A revisão deve procurar drivers que chamam remap_pfn_range() e validam intervalos com expressões aritméticas suscetíveis a estouro, especialmente somas entre deslocamento e tamanho. O padrão problemático é confiar no resultado da soma sem antes garantir que os operandos estão dentro de limites seguros. Testes unitários e fuzzing de drivers devem incluir deslocamentos extremos, tamanhos de página alinhados e combinações que tentem provocar retorno aritmético para valores baixos.

• Módulo udl carregado em hosts nos quais o dispositivo correspondente é acessível por usuários locais.
• Permissões amplas em nós de dispositivo associados a drivers gráficos, framebuffer ou periféricos que aceitam mmap().
• Processos não administrativos abrindo dispositivos privilegiados e realizando mapeamentos de memória em sequência.
• Eventos de escalonamento local de privilégio após interação com drivers de dispositivo.
• Código de driver com remap_pfn_range() e validação baseada em offset + size sem proteção explícita contra estouro inteiro.

Mitigação

A ação principal é aplicar a correção do núcleo correspondente e garantir que kernels derivados, distribuições internas e imagens de virtualização tenham incorporado o ajuste. A correção foi validada em 18 de março de 2018, portanto a resposta defensiva deve priorizar a remoção de versões vulneráveis do parque e a confirmação de que sistemas baseados no ramo afetado não permanecem em uso por dependência de compatibilidade. Em ambientes com gestão centralizada de imagens, a atualização precisa alcançar tanto hosts físicos quanto máquinas virtuais que carreguem o driver afetado.

Como contenção, administradores devem revisar permissões sobre dispositivos associados ao driver udl e a outros drivers que exponham mapeamento de memória. Quando o hardware ou a funcionalidade não for necessária, a desativação do módulo reduz a superfície de ataque. Quando o driver for necessário, o acesso deve ser restrito a grupos mínimos e justificados, com auditoria para usos fora do perfil. Essa medida não substitui o patch, mas diminui a probabilidade de que uma conta local comum consiga acionar o caminho vulnerável antes da atualização completa.

Equipes de desenvolvimento de kernel, fabricantes de drivers e mantenedores de módulos externos devem tratar o caso como referência para revisão de mmap() próprio. A validação correta precisa comparar início e fim do intervalo de modo resistente a estouro, garantir alinhamento de páginas, limitar o deslocamento ao buffer do dispositivo e recusar qualquer mapeamento que extrapole a memória compartilhada autorizada. A chamada a remap_pfn_range() deve ocorrer apenas depois dessas checagens. Revisões de segurança devem incluir casos extremos de aritmética sem sinal, porque esse tipo de erro raramente aparece em testes funcionais normais.

Após atualização ou mudança de permissão, a validação deve confirmar que o módulo corrigido está carregado, que o nó de dispositivo não ficou acessível a usuários indevidos e que tentativas de mapear intervalos fora do buffer são rejeitadas sem queda do sistema. Em sistemas onde houve suspeita de abuso, a resposta deve incluir análise de contas locais, binários com bit de privilégio alterado, serviços persistentes recém-criados e alterações em arquivos sensíveis. O objetivo é separar a correção da causa raiz da investigação de possíveis efeitos pós-exploração.

• Atualizar o núcleo Linux para uma versão que contenha a correção validada para o manipulador vulnerável.
• Remover ou bloquear o carregamento do driver udl quando a funcionalidade DisplayLink não for necessária.
• Restringir permissões de dispositivos que permitam mmap() a grupos administrativos ou contas justificadas.
• Auditar drivers internos e externos que implementam mmap() próprio e usam remap_pfn_range().
• Adicionar testes para deslocamentos extremos, tamanhos alinhados por página e condições de estouro inteiro em validações de intervalo.