ALSA: usb-audio: Fix potential out-of-bound accesses for Extigy and Mbox devices

Falha de acesso fora dos limites (out-of-bounds) no driver ALSA usb-audio do kernel Linux, nas rotinas de boot quirk para os dispositivos de áudio USB Extigy e Mbox/Mbox2/Mbox3. Um dispositivo USB malicioso pode declarar um bNumConfigurations maior que o valor originalmente usado para alocar a estrutura dev->config, corrompendo memória do kernel quando essa configuração é destruída. O vetor é estritamente local/físico — exige conectar um dispositivo USB forjado ao host — o que limita bastante quem está realmente exposto, apesar do CVSS 7.8 e da entrada no catálogo KEV da CISA.

O código problemático está em sound/usb/quirks.c, nas funções snd_usb_extigy_boot_quirk(), snd_usb_mbox2_boot_quirk() e snd_usb_mbox3_boot_quirk(). Essas rotinas enviam um comando de boot/firmware ao dispositivo e, em seguida, solicitam de novo o descritor de dispositivo via usb_get_descriptor(USB_DT_DEVICE), escrevendo o resultado diretamente sobre dev->descriptor — a mesma estrutura cujo campo bNumConfigurations foi usado anteriormente por usb_get_configuration() para alocar o array dev->config.

Como o dispositivo USB é controlado pelo atacante (pode responder qualquer valor no segundo descritor), o kernel sobrescrevia dev->descriptor sem revalidar se o novo bNumConfigurations excedia o valor original. Isso cria uma inconsistência: o kernel passa a acreditar que existem mais configurações do que foram efetivamente alocadas em memória. Código posterior que itera sobre essas configurações — o advisory cita explicitamente usb_destroy_configuration() — passa a acessar entradas fora dos limites do array alocado.

Em termos de CWE, o problema se encaixa em validação inadequada de uma quantidade especificada na entrada (CWE-1284), que se manifesta como leitura/escrita fora dos limites (CWE-125/CWE-787) dependendo do caminho de código atingido depois da inconsistência. O commit de correção referencia como origem o commit 1da177e4c3f4, que é o commit inicial do histórico git do kernel Linux (equivalente ao Linux 2.6.12-rc2) — ou seja, o código vulnerável existe desde o começo do rastreamento em git do driver.

A correção introduz uma variável local new_device_descriptor para receber o descritor relido, compara seu bNumConfigurations com o valor já presente em dev->descriptor antes de qualquer sobrescrita, e só executa o memcpy() para dev->descriptor quando o novo valor não é maior que o original. Se for maior, apenas registra um dev_dbg de erro e preserva o descritor anterior, eliminando a janela de inconsistência.

O vetor é local e físico: é preciso conectar ao host um dispositivo USB que se identifique (por VID/PID) como Extigy, Mbox, Mbox2 ou Mbox3 — os quirks de boot específicos desses periféricos de áudio — ou emular esse comportamento com hardware capaz de forjar descritores USB e responder à sequência de boot esperada. O código vulnerável só é acionado quando o kernel reconhece o dispositivo e executa a rotina de boot correspondente, que reenvia firmware e relê o descritor de dispositivo. Não há interação do usuário além do sistema processar o dispositivo plugado (refletido no UI:N do vetor CVSS), e a classificação PR:L reflete que, em muitos ambientes, plugar um dispositivo USB não exige privilégio elevado — embora em ambientes com controle de acesso a portas USB isso não seja trivial.

O impacto declarado pelo fornecedor é corrupção de memória do kernel via acesso fora dos limites, o que na prática pode causar pânico/crash do kernel (negação de serviço) e, em cenários mais graves de exploração da corrupção de memória, abrir caminho para escalonamento de privilégios ou execução de código em nível de kernel — este último não é detalhado com PoC nas fontes disponíveis, apenas inferido pelo padrão C:H/I:H/A:H do CVSS.

A presença desta CVE no catálogo KEV da CISA confirma exploração ativa observada, mas as fontes lidas não descrevem o cenário concreto de exploração (por exemplo, se ligado a ferramentas de acesso físico forense, ataques direcionados a estações de trabalho ou outro contexto). Vale reforçar: por exigir acesso físico ao barramento USB do host, o universo prático de vítimas se restringe a situações em que essa interação física é viável — quiosques, laboratórios, dispositivos desbloqueados e acessíveis fisicamente, cadeias de custódia forense, etc. — não é um vetor remoto via rede.

A correção oficial (commit upstream b909df18ce2a998afef81d58bbd1a05dc0788c40) foi retroportada para múltiplas árvores stable do kernel Linux entre 5 e 14 de dezembro de 2024, conforme os commits catalogados nas branches linux-*.y do repositório stable. As fontes consultadas não trazem o número exato de versão de release (ex.: 6.12.x, 6.6.x, 6.1.x etc.) em que cada backport foi publicado — apenas os commits nas árvores stable git.kernel.org — portanto a recomendação prática é verificar no changelog da sua distribuição/kernel se o commit citado (ou seu equivalente de backport) já foi incorporado, em vez de assumir uma versão específica.

Se a atualização do kernel não for viável de imediato, o controle compensatório real é restringir a conexão de dispositivos USB de áudio não confiáveis: políticas de allowlist de dispositivos USB (por classe/VID/PID), bloqueio de portas USB não gerenciadas, ou impedir o carregamento do módulo snd-usb-audio em sistemas que não precisam de periféricos de áudio USB. Esse controle reduz a superfície de exposição mas não corrige a falha em si — o módulo, se carregado e um dispositivo correspondente for conectado, permanece vulnerável.

Não funciona como mitigação: qualquer controle de rede — firewall, WAF, segmentação — é irrelevante, pois o vetor é local via barramento USB, não remoto.

Não há sinal de rede a monitorar, pois o vetor é local via barramento USB e a falha ocorre dentro do driver do kernel. Em kernels já corrigidos, uma mensagem dev_dbg no log do kernel (dmesg/journal) do tipo 'error too large bNumConfigurations' indica que um dispositivo tentou declarar um número de configurações inconsistente e foi bloqueado pela correção — presença dessa mensagem é sinal de tentativa de exploração ou de dispositivo malformado/malicioso. Em kernels não corrigidos, não existe esse aviso; o sintoma mais provável de exploração bem-sucedida seria um crash ou pânico do kernel associado a sound/usb/quirks.c ou usb_destroy_configuration, sem alerta prévio. Para investigação forense, revisar o histórico de dispositivos USB conectados (VID/PID via udev, usbmon) é o caminho prático, já que não existe assinatura de rede ou IOC confiável para esta falha.