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:
<pre>
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;
</pre>
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---
CVSS Vector: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 8.8
AV:A - hid-rmi matches HID_DEVICE(HID_BUS_ANY, HID_GROUP_RMI, HID_ANY_ID, HID_ANY_ID), so a Bluetooth HID/HoGP peripheral claiming Synaptics VID 0x06cb and an RMI-style descriptor is grouped HID_GROUP_RMI and bound over an adjacent wireless link; USB attach is only a lower-severity physical path.
AC:L - The attacker fully controls the HID report descriptor (undersized input/output reports) and RMI reply bytes, including the read-length byte and PDT interrupt-source counts, so probe performs the OOB read/write and optional zero-length hang with no race or other condition outside attacker control.
PR:N - A malicious HID peripheral is sufficient: hid-rmi autoloads and rmi_input_configured()/rmi_f01_probe() run during enumeration, with no local account, capability, or init-namespace privilege required on the victim.
UI:N - rmi_set_page() and rmi_hid_read_block() run from rmi_input_configured() during hid_hw_start() as soon as the device connects or auto-reconnects; no extra victim open, mount, or confirmation is required.
S:U - The heap out-of-bounds read and write corrupt host kernel memory in the HID/RMI probe path and do not cross a VM, IOMMU, or other separate security authority.
C:H - rmi_hid_read_block() copies from &readReport[2] using a device-supplied length of up to 255 bytes with no input_report_size bound, reading adjacent slab into RMI registers that are logged and exported via the world-readable product_id sysfs attribute; heap OOB reads are High confidentiality.
I:H - Undersized output reports make rmi_set_page() and rmi_hid_read_block() store past writeReport, and rmi_hid_write_block() memcpy's an unbounded PDT-derived length to &writeReport[4], overflowing the heap allocation; out-of-bounds writes are High integrity.
A:H - The heap OOB access causes a kernel oops (KASAN slab-out-of-bounds in rmi_hid_read_block/rmi_hid_write_block), and a device answering zero-length read replies loops forever in probe with page_mutex held, hanging a kworker; kernel crash or hang is High availability.
| Attack Vector |
Adjacent Network |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
None |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:A - hid-rmi matches HID_DEVICE(HID_BUS_ANY, HID_GROUP_RMI, HID_ANY_ID, HID_ANY_ID), so a Bluetooth HID/HoGP peripheral claiming Synaptics VID 0x06cb and an RMI-style descriptor is grouped HID_GROUP_RMI and bound over an adjacent wireless link; USB attach is only a lower-severity physical path.
AC:L - The attacker fully controls the HID report descriptor (undersized input/output reports) and RMI reply bytes, including the read-length byte and PDT interrupt-source counts, so probe performs the OOB read/write and optional zero-length hang with no race or other condition outside attacker control.
PR:N - A malicious HID peripheral is sufficient: hid-rmi autoloads and rmi_input_configured()/rmi_f01_probe() run during enumeration, with no local account, capability, or init-namespace privilege required on the victim.
UI:N - rmi_set_page() and rmi_hid_read_block() run from rmi_input_configured() during hid_hw_start() as soon as the device connects or auto-reconnects; no extra victim open, mount, or confirmation is required.
S:U - The heap out-of-bounds read and write corrupt host kernel memory in the HID/RMI probe path and do not cross a VM, IOMMU, or other separate security authority.
C:H - rmi_hid_read_block() copies from &readReport[2] using a device-supplied length of up to 255 bytes with no input_report_size bound, reading adjacent slab into RMI registers that are logged and exported via the world-readable product_id sysfs attribute; heap OOB reads are High confidentiality.
I:H - Undersized output reports make rmi_set_page() and rmi_hid_read_block() store past writeReport, and rmi_hid_write_block() memcpy's an unbounded PDT-derived length to &writeReport[4], overflowing the heap allocation; out-of-bounds writes are High integrity.
A:H - The heap OOB access causes a kernel oops (KASAN slab-out-of-bounds in rmi_hid_read_block/rmi_hid_write_block), and a device answering zero-length read replies loops forever in probe with page_mutex held, hanging a kworker; kernel crash or hang is High availability.
CVSS 3.1