CVE-2026-90000 in Linux
Sumário
de VulDB • 17/09/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
HID: rmi: corrige acesso fora dos limites (OOB) com relatórios RMI de tamanho insuficiente
O driver hid-rmi dimensiona seus buffers writeReport/readReport exclusivamente com base no descritor de relatório fornecido pelo dispositivo, sem um limite mínimo:
data->input_report_size = hid_report_len(input_report); data->output_report_size = hid_report_len(output_report); alloc_size = data->output_report_size + data->input_report_size; data->writeReport = devm_kzalloc(&hdev->dev, alloc_size, GFP_KERNEL); data->readReport = data->writeReport + data->output_report_size;
mas depois lê e grava em deslocamentos fixos dentro dele. Um dispositivo que declara um relatório de saída de 1 byte e um relatório de entrada de 1 byte faz com que hid_report_len() retorne 2 para cada um, então alloc_size é 4, enquanto rmi_set_page() -- alcançada incondicionalmente no momento do probe através de rmi_input_configured() -- armazena em writeReport[4] e rmi_hid_read_block() armazena em writeReport[0..5]. Como readReport está localizado em writeReport + output_report_size, essas gravações também corrompem a janela da qual a próxima resposta é analisada.
O caminho de leitura é pior: o comprimento da cópia vem de readReport[1], que o dispositivo preenche e pode ser até 255, e a cópia começa em &readReport[2] sem considerar input_report_size, então ela ultrapassa o final do alocação para objetos slab adjacentes. Isso não requer nem mesmo um dispositivo mentiroso -- rmi_f01_probe() executa uma leitura de registrador fixa de 21 bytes, portanto qualquer dispositivo que declare um relatório de entrada menor que 23 bytes lê fora dos limites mesmo quando responde com veracidade. Esses bytes tornam-se os valores do registrador sobre os quais o núcleo RMI age: rmi_f01_probe() imprime-os no log do kernel como id do produto e os exporta através do atributo sysfs de permissão 0444 com o mesmo nome, e rmi_driver_set_irq_bits() os envia de volta ao dispositivo como a máscara de interrupção, portanto um descritor de relatório de tamanho insuficiente vaza conteúdo da heap tanto para usuáriospace não privilegiado quanto para o próprio dispositivo.
O caminho de escrita também não possui limite: rmi_hid_write_block() copia um len sem limites para &writeReport[4], e o maior chamador que um dispositivo pode acionar no momento do probe é rmi_driver_set_irq_bits(), cujo comprimento é derivado das contagens de fontes de interrupção que o dispositivo declara em sua Tabela de Descrição da Página.
Finalmente, o loop de leitura não pode terminar com uma resposta de comprimento zero: tal resposta não copia nada e avança nem bytes_read nem bytes_needed, e como uma resposta chegou, a espera wait_event_timeout() de um segundo também não é acionada, então um dispositivo que responde 0 para sempre mantém o loop rodando dentro do worker de probe com page_mutex segurado. khungtaskd não percebe isso, porque toda resposta desperta a tarefa.
Rejeitar relatórios muito pequenos para o que o driver constrói -- 6 bytes de saída para os relatórios de escrita e 3 bytes de entrada para o handshake de leitura -- no momento do probe, limitar (clamp) a gravação e a cópia de leitura aos tamanhos de relatório declarados pelo dispositivo, e tratar uma resposta de comprimento zero como um erro. Um dispositivo recusado dessa forma é iniciado como um dispositivo HID comum, semelhante àquele que não possui os IDs de relatório RMI em absoluto.
RMI_DEVICE não deve permanecer definido em device_flags nesse caminho, porque rmi_input_configured() então executaria a configuração do RMI e alcançaria rmi_set_page(), que grava no buffer writeReport cuja alocação foi apenas ignorada pela recusa. O bit pode chegar definido: rmi_probe() copia id->driver_data para device_flags antes das verificações de relatório, e um bind através do atributo sysfs new_id pode fornecer driver_data com RMI_DEVICE (BIT(0)) definido. Remover o bit onde driver_data é copiado, para que RMI_DEVICE mantenha exatamente o significado "este probe validou os relatórios"; as três saltos iniciais para iniciar isso também são cobertos por esta correção.
O caminho de erro também limpa RMI_READ_DATA_PENDING em sua saída, porque esse flag é o que a espera no topo do loop testa: deixá-lo definido faria com que toda wait_event_timeout() subsequente retornasse imediatamente na resposta obsoleta e mataria o caminho de leitura pelo resto da vida útil do dispositivo.
A limitação (clamping) não regressiona hardware funcional: o loop de leitura já lida com ---truncated---
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.