HID: core: zero-initialize the report buffer

Falha no núcleo do subsistema HID do Linux (drivers/hid/hid-core.c): o buffer usado para armazenar relatórios (reports) de dispositivos HID era alocado com kmalloc() sem zerar a memória, permitindo que bytes residuais de alocações anteriores do heap do kernel fossem expostos de volta ao espaço de usuário através de um relatório HID malformado. É uma vulnerabilidade de vazamento de memória do kernel (confidencialidade), não de execução de código ou negação de serviço. Importa porque está confirmada no catálogo KEV da CISA como explorada ativamente, tipicamente como elo de uma cadeia de exploração local/física contra dispositivos (inclusive Android), não como bug remoto crítico isolado.

A função hid_alloc_report_buf(), em drivers/hid/hid-core.c, calcula o tamanho do buffer de relatório com hid_report_len(report) + 7 e alocava esse espaço com kmalloc(len, flags). Esse buffer é genérico e usado por praticamente todos os drivers HID (USB, Bluetooth, I2C-HID, uhid) para montar e transmitir relatórios GET_REPORT/SET_REPORT. O problema é que nem todo caminho de código preenche o buffer inteiro antes de ele ser lido de volta pelo espaço de usuário — se o relatório processado for menor que o tamanho alocado, os bytes finais permanecem com o conteúdo antigo da alocação de heap anterior.

O advisory associa a causa raiz ao commit 27ce405039bf ("HID: fix data access in implement()"), que alterou a forma como os dados são manipulados na função implement() sem garantir inicialização completa do buffer. Isso se enquadra em CWE-908 (uso de recurso não inicializado), com consequência de CWE-200 (exposição de informação) — um atacante que controla o conteúdo ou o tamanho de um relatório HID pode fazer o kernel devolver, junto com dados legítimos, fragmentos de memória do kernel que estavam naquela região do heap antes da alocação.

A correção é mínima: trocar kmalloc(len, flags) por kzalloc(len, flags) em hid_alloc_report_buf(), garantindo que todo buffer novo comece zerado, eliminando a possibilidade de vazamento por bytes não escritos, independentemente de qual driver HID específico manipule o relatório depois.

O vetor exige que o atacante consiga fazer o kernel alocar e devolver um buffer de relatório HID — ou seja, precisa de um caminho para enviar/receber relatórios HID processados pelo core (drivers/hid/hid-core.c). Isso é possível controlando um dispositivo HID (USB ou Bluetooth) conectado à máquina alvo, ou tendo acesso a interfaces como /dev/hidraw* ou /dev/uhid, que permitem criar dispositivos HID virtuais e trocar relatórios sem hardware físico. O CVSS reportado (AV:L/AC:L/PR:L/UI:N) reflete exatamente isso: é um vetor local, sem interação do usuário, mas que requer algum nível de privilégio/acesso local — não é explorável remotamente pela rede.

Na prática, a técnica consiste em forçar a alocação de um buffer maior que o payload real do relatório e depois ler esse buffer de volta (via leitura de hidraw, resposta a GET_REPORT, ou caminho equivalente do driver), obtendo como retorno memória de heap do kernel que não pertence ao relatório. Esse tipo de vazamento normalmente serve como primitiva de leitura de kernel dentro de uma cadeia maior de exploração (por exemplo, para derrotar KASLR ou obter ponteiros/segredos que viabilizem escalonamento de privilégios com outra falha).

A CVE está no catálogo KEV da CISA, confirmando exploração real. É de conhecimento público que múltiplas CVEs do subsistema USB/HID do kernel Linux divulgadas nesse período (incluindo esta) foram associadas por pesquisadores de segurança a cadeias de exploração usadas por ferramentas forenses/comerciais para desbloquear ou comprometer dispositivos Android físicos apreendidos — cenário compatível com o vetor local/físico exigido aqui. Essa atribuição específica não está nas fontes técnicas do kernel revisadas nesta página; trate-a como contexto de risco, não como fato verificado por esta análise.

A correção definitiva é atualizar o kernel Linux para uma versão que contenha o commit que troca kmalloc() por kzalloc() em hid_alloc_report_buf() (drivers/hid/hid-core.c). O fix foi mesclado no mainline pelo commit 177f25d1292c7e16e1199b39c85480f7f8815552 e distribuído para diversos branches -stable/LTS ativos via backports como o commit 05ade5d4337867929e7ef664e7ac8e0c734f1aaf. As fontes revisadas não trazem os números exatos de versão/patch (ex.: 6.x.y) em que cada branch recebeu o backport — confirme o changelog do seu branch -stable específico antes de declarar corrigido.

Não há paliativo de configuração real: como a falha está na função central de alocação de buffer usada por todo o subsistema HID, desativar drivers HID individuais não elimina o caminho vulnerável, apenas reduz a superfície de dispositivos que passam por ele. Restringir acesso físico a portas USB/Bluetooth e a permissões de /dev/hidraw* e /dev/uhid (via udev rules, LSM, ou políticas de dispositivo) reduz a chance de exploração, mas não corrige o vazamento em si.

Mito a evitar: isolar a aplicação de espaço de usuário (sandboxing) não mitiga o problema, porque o vazamento ocorre dentro do próprio kernel antes de qualquer dado chegar ao processo — o controle efetivo é impedir a entrada do relatório malformado (via restrição de acesso ao hardware/interfaces HID) ou aplicar o patch.

Não há assinatura de rede ou log padrão confiável para esta falha: a exploração ocorre inteiramente dentro do kernel, via interação local com o subsistema HID (dispositivo USB/Bluetooth físico ou interfaces /dev/hidraw*, /dev/uhid), e o vazamento de memória não gera necessariamente erro ou mensagem em dmesg. Ambientes que registram acesso a /dev/hidraw* e /dev/uhid, ou que monitoram conexão de dispositivos USB/Bluetooth HID não usuais (especialmente em contextos de perícia forense ou desbloqueio físico de dispositivo), podem correlacionar esses eventos como indicador contextual, mas isso não constitui detecção específica da CVE-2024-50302.