media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in uvc_parse_format

Falha de out-of-bounds write no driver uvcvideo do kernel Linux, que parseia os descritores USB Video Class (UVC) enviados por webcams e outros dispositivos de vídeo USB. Um dispositivo UVC malicioso pode declarar um frame do tipo UVC_VS_UNDEFINED que não é contabilizado no cálculo de tamanho do buffer de frames, mas é processado como se fosse válido, corrompendo memória do kernel. Está no catálogo KEV da CISA como exploração confirmada, mas o vetor real — descritor USB malicioso vindo de um dispositivo físico ou emulado — é bem mais restrito do que o CVSS 7.8 sugere para quem pensa em ataque remoto de rede.

O bug está em uvc_parse_format(), em drivers/media/usb/uvc/uvc_driver.c. A função percorre os descritores VS_FORMAT/VS_FRAME que o dispositivo USB expõe durante a enumeração, contando quantos frames existem para calcular o tamanho do buffer que será alocado em uvc_parse_streaming(). O loop que faz esse parsing usava apenas a condição 'buflen > 2 && buffer[1] == USB_DT_CS_INTERFACE && buffer[2] == ftype', sem checar se ftype era diferente de zero (UVC_VS_UNDEFINED = 0).

O cálculo de tamanho em uvc_parse_streaming ignora frames do tipo UVC_VS_UNDEFINED — ou seja, eles não entram na contagem usada para dimensionar o buffer. Mas uvc_parse_format continuava iterando e gravando dados desses frames no buffer já alocado, que ficou menor do que necessário. Resultado: escrita fora dos limites do heap do kernel (CWE-787, out-of-bounds write; a raiz é um cálculo de tamanho de buffer inconsistente com o que é efetivamente parseado, CWE-131).

O atacante controla o conteúdo dos descritores USB do dispositivo — quantidade e tipo dos frames, e os bytes que seriam escritos na estrutura de frame durante o parsing. Isso dá alguma capacidade de moldar o que é escrito fora dos limites, o que em tese abre caminho para corrupção de estrutura adjacente no heap, não apenas um crash.

A falha existe desde a introdução do parsing de descritores no driver (commit c0efd232929c, 'V4L/DVB (8145a): USB Video Class driver'), ou seja, faz parte do código desde as primeiras versões do driver uvcvideo — não é uma regressão recente.

O vetor de ataque é um dispositivo USB Video Class malicioso — uma webcam, capturadora ou qualquer periférico que se anuncie como classe UVC — conectado à porta USB do host, ou um dispositivo USB emulado por hardware programável. O host precisa carregar o driver uvcvideo e enumerar esse dispositivo, o que acontece automaticamente ao plugar qualquer câmera USB padrão; não há necessidade de o usuário abrir aplicativo algum (UI:N no vetor CVSS).

O CVSS classifica o vetor de ataque como local (AV:L) e exige privilégio baixo (PR:L) — isso reflete que a superfície de exploração é a pilha USB local do kernel, acionada pela conexão física de um dispositivo, e não uma falha explorável remotamente pela rede. Em ambientes onde portas USB são acessíveis a terceiros (quiosques, estações compartilhadas, laboratórios, dispositivos IoT com portas USB expostas) ou onde há passthrough de USB para máquinas virtuais, o pré-requisito de 'acesso local' se traduz em risco real de comprometimento a partir de um pendrive/dispositivo aparentemente inofensivo.

O resultado da exploração bem-sucedida é corrupção de memória no kernel, com potencial de negação de serviço (crash) e, dependendo de como o atacante molda os bytes gravados fora dos limites, escalonamento de privilégios ou execução de código em contexto de kernel. O CVE está no catálogo KEV da CISA, indicando exploração confirmada; as fontes disponíveis não detalham campanha específica, atribuição de ator ou o exploit usado — apenas o mecanismo do bug e a correção.

A correção é o commit upstream ecf2b43018da9579842c774b7f35dbe11b5c38dd, que adiciona a checagem 'ftype &&' ao loop de parsing em uvc_parse_format(), fazendo o driver pular frames do tipo UVC_VS_UNDEFINED em vez de processá-los. O patch foi retroportado para múltiplas séries do kernel estável mantidas em kernel.org (branches linux-*.y, de 2.6.x até as séries 6.x mais recentes, conforme os commits individuais referenciados). As fontes consultadas não trazem os números de release exatos (ex.: qual patch-level de 6.12.y ou 6.11.y) em que cada backport foi incorporado — confirme isso no changelog da distribuição ou do kernel específico em uso antes de considerar o sistema corrigido.

Se a atualização do kernel não for possível de imediato, o controle compensatório real é restringir a exposição de portas USB físicas em máquinas sensíveis (bloqueio de portas, USBGuard, política de whitelist de dispositivos por classe/VID-PID) e desabilitar ou restringir o passthrough USB para máquinas virtuais quando não for estritamente necessário. Descarregar o módulo uvcvideo (blacklist) elimina a superfície de ataque em hosts que não usam webcams/capturadoras UVC, ao custo de perder a funcionalidade de vídeo USB.

Não funciona como mitigação: firewall de rede ou WAF, já que a falha não é acessível pela rede; e antivírus de userspace, já que o bug está na camada de driver do kernel, antes de qualquer processo de usuário processar os dados do dispositivo.

Não há assinatura de rede a procurar, pois a falha é acionada pela pilha USB local durante a enumeração de um dispositivo de vídeo, não por tráfego de rede. Sinais possíveis em ambientes controlados: logs do kernel (dmesg/journalctl) mostrando crashes ou warnings do subsistema uvcvideo/usbcore relacionados a parsing de descritores logo após a conexão de um dispositivo USB; em sistemas com KASAN ou outras ferramentas de detecção de corrupção de memória habilitadas, alertas de out-of-bounds write originados em uvc_parse_format/uvc_parse_streaming são o indício mais direto. Sem essas instrumentações, a exploração pode não deixar rastro identificável antes de causar crash ou comprometimento — é informação relevante para quem depende apenas de logs padrão.