CVE-2026-90000: HID: rmi: fix OOB access with undersized RMI reports

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->inputreportsize = hidreportlen(inputreport); data->outputreportsize = hidreportlen(outputreport); allocsize = data->outputreportsize + data->inputreportsize; data->writeReport = devmkzalloc(&hdev->dev, allocsize, GFPKERNEL); data->readReport = data->writeReport + data->outputreportsize;

but then reads and writes fixed offsets into it. A device declaring a 1-byte output and a 1-byte input report makes hidreportlen() return 2 for each, so allocsize is 4, while rmisetpage() -- reached unconditionally at probe time through rmiinputconfigured() -- stores writeReport[4] and rmihidreadblock() stores writeReport[0..5]. Since readReport lives at writeReport + outputreportsize, 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 inputreportsize, so it runs past the end of the allocation into adjacent slab objects. This does not even need a lying device -- rmif01probe() 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: rmif01probe() prints them to the kernel log as the product id and exports them through the mode 0444 sysfs attribute of the same name, and rmidriversetirqbits() 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: rmihidwriteblock() copies an unbounded len to &writeReport[4], and the largest caller a device can drive at probe time is rmidriversetirqbits(), 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 bytesread nor bytesneeded, and because a reply did arrive the one second waiteventtimeout() does not fire either, so a device answering 0 forever keeps the loop running inside the probe worker with pagemutex 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.

RMIDEVICE must not be left set in deviceflags on that path, because rmiinputconfigured() would then run the RMI setup and reach rmisetpage(), which writes the writeReport buffer the refusal just skipped allocating. The bit can arrive set: rmiprobe() copies id->driverdata into deviceflags before the report checks, and a bind through the newid sysfs attribute can supply driverdata with RMIDEVICE (BIT(0)) set. Strip the bit where driverdata is copied, so RMIDEVICE 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 RMIREADDATAPENDING 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 waiteventtimeout() 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---