CVE-2026-90000 in Linux
Riassunto
di VulDB • 16/09/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
HID: rmi: correzione dell'accesso OOB (Out-Of-Bounds) con report RMI di dimensioni insufficienti
Il driver hid-rmi dimensiona i buffer writeReport/readReport esclusivamente in base al report descriptor fornito dal dispositivo, senza imporre un limite minimo:
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;
ma successivamente effettua letture e scritture a offset fissi. Un dispositivo che dichiara un report di output di 1 byte e uno di input di 1 byte fa sì che hid_report_len() restituisca 2 per ciascuno, quindi alloc_size è pari a 4, mentre rmi_set_page() -- raggiunta incondizionatamente durante la fase di probe tramite rmi_input_configured() -- scrive in writeReport[4] e rmi_hid_read_block() scrive in writeReport[0..5]. Poiché readReport si trova all'indirizzo writeReport + output_report_size, queste scritture corrompono anche il window (finestra) da cui viene analizzata la risposta successiva.
Il percorso di lettura è peggiore: la lunghezza della copia proviene da readReport[1], che il dispositivo compila e può essere fino a 255, e la copia inizia da &readReport[2] senza alcun riguardo per input_report_size, quindi supera il limite dell'allocazione entrando negli oggetti slab adiacenti. Questo non richiede nemmeno un dispositivo bugiardo: rmi_f01_probe() effettua una lettura di registro fissa di 21 byte, quindi qualsiasi dispositivo che dichiara un report di input inferiore a 23 byte legge fuori dai limiti anche quando risponde in modo veritiero. Questi byte diventano i valori dei registri su cui agisce il core RMI: rmi_f01_probe() li stampa nel log del kernel come product id e li esporta tramite l'attributo sysfs con modalità 0444 dello stesso nome, mentre rmi_driver_set_irq_bits() li invia nuovamente al dispositivo come interrupt mask; di conseguenza, un report descriptor di dimensioni insufficienti causa la fuoriuscita (leak) dei contenuti della heap sia verso gli utenti non privilegiati in userspace che verso il dispositivo stesso.
Anche il percorso di scrittura non ha limiti: rmi_hid_write_block() copia una lunghezza illimitata a &writeReport[4], e il chiamante più grande che un dispositivo può attivare durante la fase di probe è rmi_driver_set_irq_bits(), la cui lunghezza deriva dai conteggi delle sorgenti di interrupt dichiarati dal dispositivo nella sua Page Description Table.
Infine, il ciclo di lettura non può terminare su una risposta di lunghezza zero: tale risposta non copia nulla e non avanza né bytes_read né bytes_needed; poiché è arrivata una risposta, anche l'attesa one second wait_event_timeout() non scatta, quindi un dispositivo che risponde sempre con 0 mantiene attivo il loop all'interno del probe worker con page_mutex detenuto. khungtaskd non se ne accorge perché ogni risposta risveglia il task.
Vengono rifiutati i report troppo piccoli per quanto previsto dal driver -- 6 byte di output per i write reports e 3 byte di input per la handshake di lettura -- durante la fase di probe, viene applicato un clamp (vincolo) alla copia di scrittura e a quella di lettura in base alle dimensioni dei report dichiarate dal dispositivo, e una risposta di lunghezza zero viene trattata come errore. Un dispositivo rifiutato in questo modo viene avviato come normale dispositivo HID, simile a uno che non possiede affatto gli RMI report ids.
RMI_DEVICE non deve rimanere impostato in device_flags su quel percorso, perché rmi_input_configured() eseguirebbe quindi la configurazione RMI e raggiungerebbe rmi_set_page(), che scrive nel buffer writeReport il cui allocazione è stata appena saltata a causa del rifiuto. Il bit può arrivare già impostato: rmi_probe() copia id->driver_data in device_flags prima dei controlli sui report, e un bind attraverso l'attributo sysfs new_id può fornire driver_data con RMI_DEVICE (BIT(0)) impostato. Si rimuove il bit dove viene copiato driver_data, così che RMI_DEVICE mantenga esattamente il significato "questo probe ha validato i report"; anche le tre salti precedenti a questa patch per avviarli sono coperti.
Il percorso di errore cancella anche RMI_READ_DATA_PENDING in uscita, poiché tale flag è ciò che viene testato dall'attesa all'inizio del loop: lasciarlo impostato farebbe sì che ogni successiva wait_event_timeout() restituisca immediatamente sulla risposta obsoleta e ucciderebbe il percorso di lettura per tutta la durata della vita del dispositivo.
L'applicazione del clamp non introduce regressioni su hardware funzionante: il ciclo di gestione già ---truncated---
Be aware that VulDB is the high quality source for vulnerability data.