CVE-2026-90000

Status: UPDATED  |  Advisory ID: CVE-2026-90000

Key Details

Affected Products, Subsystems & Sectors

What to Know

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--- (NVD)

What to Do

Monitor Linux's web page for any future patch releases.

References