ALSA: usb-audio: Fix out of bounds reads when finding clock sources

Falha de leitura fora dos limites (out-of-bounds read) no driver ALSA usb-audio do kernel Linux, ao processar descritores de clock (UAC2/UAC3) de dispositivos USB de áudio. O driver não validava o campo bLength dos descritores antes de acessá-los, então um dispositivo USB malicioso pode fornecer um descritor de clock deliberadamente curto e forçar o kernel a ler memória adjacente fora do buffer do descritor. O vetor exige acesso físico/local ao barramento USB (AV:L), não é explorável remotamente pela rede.

O código em sound/usb/clock.c percorre os descritores de configuração USB do dispositivo de áudio procurando por clock source, clock selector e clock multiplier descriptors (definidos pelas especificações UAC2 e UAC3). As funções validate_clock_source(), validate_clock_selector() e validate_clock_multiplier() comparavam apenas o campo bClockID do descritor contra o ID buscado, sem antes checar se o bLength reportado pelo dispositivo era grande o suficiente para conter a struct esperada. Isso é uma instância clássica de CWE-125 (Out-of-bounds Read): o parser confia no tamanho declarado pelo próprio dispositivo (dado não confiável) para decidir quantos bytes acessar.

O caso mais grave é o clock selector descriptor, que tem tamanho variável: além dos campos fixos, contém um array baCSourceID de bNrInPins elementos e mais dois campos no final (bmControls e iClockSelector no UAC2; bmControls de 4 bytes e wCSelectorDescrStr de 2 bytes no UAC3). Um dispositivo que declare um bNrInPins alto mas um bLength curto faz o driver ler além do buffer alocado para o descritor ao tentar acessar esse array e os campos finais.

O atacante controla o conteúdo do descritor de configuração USB do dispositivo (firmware sob seu controle) — inclusive bLength, bClockID, bNrInPins e a presença/ausência dos campos que deveriam vir depois. O buffer lido é o descriptor buffer alocado internamente pelo kernel ao enumerar o dispositivo; a leitura fora dos limites pode vazar bytes de memória kernel adjacente ou, dependendo do layout, provocar acesso a memória inválida e crash.

A correção adiciona macros de checagem (DESC_LENGTH_CHECK) que comparam bLength contra sizeof() da struct correspondente antes de qualquer dereferência, e para o clock selector soma também bNrInPins mais os campos de cauda ao cálculo do tamanho mínimo exigido. Descritores que falham na checagem são simplesmente pulados no loop de busca.

A exploração requer que o atacante controle o firmware/descritores de um dispositivo USB de áudio (real ou emulado) — cenário típico de ataque com dispositivo USB malicioso ('BadUSB' de classe áudio) conectado fisicamente à porta USB da máquina alvo, ou um hub/controlador USB comprometido capaz de apresentar descritores arbitrários. O parsing ocorre automaticamente durante a enumeração do dispositivo pelo kernel, sem exigir que o usuário interaja com nenhuma interface além de conectar o periférico — por isso o vetor CVSS marca UI:N, mas na prática o pré-requisito real é acesso físico ao barramento USB (AV:L) e privilégio local mínimo (PR:L) para que a enumeração do dispositivo seja processada pelo kernel.

O resultado prático de uma exploração bem-sucedida é leitura de memória kernel fora dos limites do buffer do descritor (impacto de confidencialidade) e, potencialmente, um acesso a página inválida que derruba o kernel (negação de serviço) — coerente com o vetor C:H/A:H/I:N do CVSS. Não há impacto de integridade reportado; a falha não permite escrita, apenas leitura indevida.

O reporte original foi atribuído a um pesquisador do Google (Benoît Sevens), o que indica descoberta via fuzzing/análise de segurança de drivers USB, não exploração selvagem observada por terceiros nas fontes técnicas consultadas. As referências disponíveis (commits do kernel.org e a thread de patch em lore.kernel.org) não trazem detalhes de campanha de exploração ativa; a afirmação de presença em catálogo KEV consta nos dados de entrada fornecidos, mas não pôde ser confirmada nas fontes técnicas lidas para esta página — um cenário de exploração em massa é atipicamente raro para uma falha que exige acesso físico ao barramento USB, então essa classificação, se correta, provavelmente reflete um caso de uso específico (ex.: ataque físico direcionado, dispositivo forense, laboratório) e não exploração remota generalizada.

A correção está nos commits identificados (a3dd4d63eeb452cfb064a13862fb376ab108f6a6 no mainline, com backports para as branches stable listados nas referências). Atualize para um kernel que já inclua esse commit em sound/usb/clock.c. As fontes lidas não trazem a lista exata de números de versão de release (ex.: 6.12.x, 6.6.x, 6.1.x, 5.15.x) em que cada backport foi publicado — confirme a presença do commit no changelog da distribuição/kernel específico antes de considerar corrigido, em vez de assumir por número de versão.

Como paliativo real quando não é possível atualizar imediatamente: restringir ou desabilitar o acesso a portas USB não confiáveis (política de USB, bloqueio de novos dispositivos de classe áudio via udev/USBGuard, ou desabilitar hot-plug USB em máquinas de alto risco) reduz a superfície, já que a falha exige um dispositivo controlado pelo atacante. Não é uma mitigação no driver, mas reduz a chance de exposição ao vetor físico.

Não funciona como mitigação: firewall de rede, WAF ou qualquer controle de perímetro — a falha está inteiramente no processamento local do barramento USB durante enumeração de dispositivo, sem componente de rede envolvido.

Não há assinatura de rede a procurar — o vetor é local, via enumeração de dispositivo USB. Em ambientes com KASAN, UBSAN ou outras ferramentas de sanitização de memória habilitadas, uma tentativa de exploração deve gerar um report de out-of-bounds read no dmesg/journal referenciando sound/usb/clock.c ou as funções validate_clock_*. Em kernels sem sanitizers, a exploração pode não deixar rastro confiável além de um eventual crash (oops/panic) no momento da enumeração do dispositivo de áudio USB; monitorar logs de kernel por oops relacionados a usb-audio no momento em que um novo dispositivo de áudio é conectado é o sinal prático disponível.