Odebrany

CVE-2026-90000

opublikowano: 16.09.2026, 13:17

modyfikacja: 16.09.2026, 17:18

Ocena CVSS

n/a

Brak oceny

Oficjalne źródła

>_ Opis

Tłumaczenie automatyczne – może zawierać nieścisłości.

W jądrze Linuksa usunięto następującą lukę:

HID: rmi: napraw dostęp OOB z niewymiarowymi raportami RMI

Sterownik hid-rmi określa rozmiar bufora writeReport/readReport wyłącznie na podstawie
deskryptor raportu dostarczony przez urządzenie, bez ograniczenia minimalnego:

dane->input_report_size = hid_report_len(input_report);
dane->rozmiar_raportu_wyjściowego = ukryty_raport_len(raport_wyjściowy);
alloc_size = dane->rozmiar_raportu_wyjściowego + dane->rozmiar_raportu_wejściowego;
dane->writeReport = devm_kzalloc(&hdev->dev, alloc_size, GFP_KERNEL);
dane->readReport = dane->writeReport + dane->output_report_size;

ale następnie odczytuje i zapisuje w nim stałe przesunięcia. Urządzenie deklarujące a
1-bajtowy raport wyjściowy i 1-bajtowy raport wejściowy powodują, że funkcja hid_report_len() zwraca wartość 2
dla każdego, więc alloc_size wynosi 4, a rmi_set_page() -- osiągnięto
bezwarunkowo w czasie sondy poprzez rmi_input_configured() -- store
writeReport[4] i rmi_hid_read_block() przechowują writeReport[0..5]. Od
readReport znajduje się w writeReport + Output_report_size, te sklepy również
uszkodzić okno, z którego będzie analizowana następna odpowiedź.

Gorsza jest ścieżka odczytu: długość kopii pochodzi z readReport[1], który
urządzenie się zapełnia i może wynosić do 255, a kopiowanie zaczyna się od
&readReport[2] bez względu na input_report_size, więc przebiega obok
koniec alokacji do sąsiednich obiektów płytowych. To nawet nie
potrzebujesz urządzenia leżącego — rmi_f01_probe() wystawia stały rejestr 21-bajtowy
read, więc każde urządzenie deklarujące raport wejściowy mniejszy niż 23 bajty
czyta poza granicami, nawet jeśli odpowiada zgodnie z prawdą. Te bajty stają się
wartości rejestrów, na które oddziałuje rdzeń RMI: rmi_f01_probe() wypisuje je
log jądra jako identyfikator produktu i eksportuje je w trybie 0444
sysfs o tej samej nazwie, a funkcja rmi_driver_set_irq_bits() wysyła
je z powrotem do urządzenia jako maskę przerwań, więc raport jest za mały
deskryptor wycieka zawartość sterty zarówno do nieuprzywilejowanej przestrzeni użytkownika, jak i do
samo urządzenie.

Ścieżka zapisu również nie jest ograniczona: rmi_hid_write_block() kopiuje plik
nieograniczona długość do &writeReport[4] i największy obiekt wywołujący, jaki może wykonać urządzenie
napędem w czasie próbkowania jest rmi_driver_set_irq_bits(), którego długość wynosi
pochodzące ze źródła przerwań, które urządzenie deklaruje na swojej stronie
Opis Tabela.

Wreszcie pętla odczytu nie może zakończyć się odpowiedzią o zerowej długości: np
odpowiedź niczego nie kopiuje i nie przesuwa ani bajtów_przeczytanych, ani bajtów_potrzebnych,
a ponieważ odpowiedź dotarła, następuje to w ciągu jednej sekundy funkcji Wait_event_timeout().
również nie uruchamia się, więc urządzenie odpowiadające 0 na zawsze utrzymuje pętlę w działaniu
wewnątrz procesu roboczego sondy z wstrzymanym page_mutex. khungtaskd nie
zauważ, bo każda odpowiedź budzi zadanie.

Odrzuć raporty zbyt małe w stosunku do tego, co buduje sterownik — 6 bajtów wyjściowych
dla raportów zapisu i 3 bajty wejściowe dla uzgadniania odczytu – at
czas sondy, zablokuj zapis i kopię odczytu do rozmiarów raportu
zadeklarowane urządzenie i potraktuj odpowiedź o zerowej długości jako błąd. Urządzenie
odrzucony w ten sposób, jest uruchamiany jako zwykłe urządzenie HID, np. takie
w ogóle nie zawiera identyfikatorów raportów RMI.

Nie można pozostawić opcji RMI_DEVICE ustawionej w flagach urządzeń na tej ścieżce, ponieważ
rmi_input_configured() uruchomi następnie konfigurację RMI i osiągnie
rmi_set_page(), która zapisuje w buforze writeReport właśnie odmowę
pominąłem przydzielanie. Bit może zostać ustawiony: rmi_probe() kopiuje
id->driver_data do flag_urządzenia przed sprawdzeniem raportu i powiązaniem
poprzez atrybut new_id sysfs może dostarczyć dane sterownika
RMI_DEVICE (BIT(0)) ustawione. Usuń fragment, w którym kopiowane są dane_sterownika, tzw
RMI_DEVICE nadal oznacza dokładnie „ta sonda zweryfikowała raporty”; the
uwzględniono także trzy skoki na początek, które poprzedzały tę łatkę.

Ścieżka błędu czyści również RMI_READ_DATA_PENDING na wyjściu, ponieważ
ta flaga jest tym, co czeka na testach na górze pętli: pozostawienie jej ustawionej
sprawiłoby, że każde późniejsze Wait_event_timeout() zwróciłoby się natychmiast
nieaktualna odpowiedź i zabicie ścieżki odczytu na resztę życia urządzenia.

Zaciskanie nie powoduje regresji działającego sprzętu: pętla odczytu już
uchwyty
---obcięty---

In the Linux kernel, the following vulnerability has been resolved:

HID: rmi: fix OOB access with undersized RMI reports

The hid-rmi driver sizes its writeReport/readReport buffer purely from
the report descriptor supplied by the device, with no minimum bound:

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;

but then reads and writes fixed offsets into it. A device declaring a
1-byte output and a 1-byte input report makes hid_report_len() return 2
for each, so alloc_size is 4, while rmi_set_page() -- reached
unconditionally at probe time through rmi_input_configured() -- stores
writeReport[4] and rmi_hid_read_block() stores writeReport[0..5]. Since
readReport lives at writeReport + output_report_size, those stores also
corrupt the window the next reply is parsed out of.

The read path is worse: the copy length comes from readReport[1], which
the device fills in and can be up to 255, and the copy starts at
&readReport[2] with no regard for input_report_size, so it runs past the
end of the allocation into adjacent slab objects. This does not even
need a lying device -- rmi_f01_probe() issues a fixed 21-byte register
read, so any device declaring an input report smaller than 23 bytes
reads out of bounds even when it answers truthfully. Those bytes become
the register values the RMI core acts on: rmi_f01_probe() prints them to
the kernel log as the product id and exports them through the mode 0444
sysfs attribute of the same name, and rmi_driver_set_irq_bits() sends
them back to the device as the interrupt mask, so an undersized report
descriptor leaks heap contents both to unprivileged userspace and to the
device itself.

The write path has no bound either: rmi_hid_write_block() copies an
unbounded len to &writeReport[4], and the largest caller a device can
drive at probe time is rmi_driver_set_irq_bits(), whose length is
derived from the interrupt source counts the device declares in its Page
Description Table.

Finally, the read loop cannot terminate on a zero-length reply: such a
reply copies nothing and advances neither bytes_read nor bytes_needed,
and because a reply did arrive the one second wait_event_timeout() does
not fire either, so a device answering 0 forever keeps the loop running
inside the probe worker with page_mutex held. khungtaskd does not
notice, because every reply wakes the task.

Reject reports too small for what the driver builds -- 6 output bytes
for the write reports and 3 input bytes for the read handshake -- at
probe time, clamp the write and the read copy to the report sizes the
device declared, and treat a zero-length reply as an error. A device
refused this way is started as an ordinary HID device, like one that
does not carry the RMI report ids at all.

RMI_DEVICE must not be left set in device_flags on that path, because
rmi_input_configured() would then run the RMI setup and reach
rmi_set_page(), which writes the writeReport buffer the refusal just
skipped allocating. The bit can arrive set: rmi_probe() copies
id->driver_data into device_flags before the report checks, and a bind
through the new_id sysfs attribute can supply driver_data with
RMI_DEVICE (BIT(0)) set. Strip the bit where driver_data is copied, so
RMI_DEVICE keeps meaning exactly "this probe validated the reports"; the
three jumps to start that predate this patch are covered as well.

The error path also clears RMI_READ_DATA_PENDING on its way out, because
that flag is what the wait at the top of the loop tests: leaving it set
would make every later wait_event_timeout() return immediately on the
stale reply and kill the read path for the rest of the device's life.

Clamping does not regress working hardware: the read loop already
handles
---truncated---

>_ Referencje

Dane podatności pochodzą z oficjalnych źródeł (CVE® List / NVD). Opisy po polsku są tłumaczone automatycznie i mogą zawierać nieścisłości – na stronie rekordu można wyświetlić wersję angielską.

This product uses the NVD API but is not endorsed or certified by the NVD.

CVE Usage: MITRE hereby grants you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Common Vulnerabilities and Exposures (CVE®). Any copy you make for such purposes is authorized provided that you reproduce MITRE's copyright designation and this license in any such copy. ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN PROVIDED BY MITRE ARE PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND.

NVD Terms of Use / CVE® Terms of Use / nvd.nist.gov / cve.org

<< baza_cve