HID: rmi: fix OOB access with undersized RMI reports

MITRE NVD CVE.ORG JSON API

Summary

CVECVE-2026-90000
StatePUBLISHED
AssignerLinux
Source PriorityCVE Program / NVD first with legacy fallback
Published2026-09-16 11:17:11 UTC
Updated2026-09-16 15:18:23 UTC
DescriptionIn 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---

Risk And Classification

Primary CVSS: v3.1 8.8 HIGH from 416baaa9-dc9f-4396-8d5f-8c081fb06d67

CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

VersionSourceTypeScoreSeverityVector
3.1416baaa9-dc9f-4396-8d5f-8c081fb06d67Secondary8.8HIGHCVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
3.1CNADECLARED8.8HIGHCVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

CVSS v3.1 Breakdown

Attack Vector
Adjacent
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Vendor Declared Affected Products

SourceVendorProductVersionPlatforms
CNA Linux Linux affected 9fb6bf02e3ad04c20edb8e46536ce3eeda32c736 fba600d824597b2a894ecae72fc422c2b8c08f8c git Not specified
CNA Linux Linux affected 9fb6bf02e3ad04c20edb8e46536ce3eeda32c736 056ef8e6700b8b6ca11453a9d4bfb1b868a5cd88 git Not specified
CNA Linux Linux affected 9fb6bf02e3ad04c20edb8e46536ce3eeda32c736 183da103022ec11af55ba9951d2cc171fb6c836b git Not specified
CNA Linux Linux affected 9fb6bf02e3ad04c20edb8e46536ce3eeda32c736 a8be8bbf0952bb7ff46636ead1896769c381fe55 git Not specified
CNA Linux Linux affected 9fb6bf02e3ad04c20edb8e46536ce3eeda32c736 ab2958e0c94edd63315dd14dc548874cc63a4043 git Not specified
CNA Linux Linux affected 9fb6bf02e3ad04c20edb8e46536ce3eeda32c736 f4cb9c4556dcb593e66dbb855179dbd351dbb053 git Not specified
CNA Linux Linux affected 9fb6bf02e3ad04c20edb8e46536ce3eeda32c736 48934c2927414a37a7fadeb6091113177c0b2038 git Not specified
CNA Linux Linux affected 9fb6bf02e3ad04c20edb8e46536ce3eeda32c736 4956993bb3befdf791d71a4952d8d13bcfd44c7b git Not specified
CNA Linux Linux affected 3.16 Not specified
CNA Linux Linux unaffected 3.16 semver Not specified
CNA Linux Linux unaffected 5.10.270 5.10.* semver Not specified
CNA Linux Linux unaffected 5.15.221 5.15.* semver Not specified
CNA Linux Linux unaffected 6.1.188 6.1.* semver Not specified
CNA Linux Linux unaffected 6.6.157 6.6.* semver Not specified
CNA Linux Linux unaffected 6.12.110 6.12.* semver Not specified
CNA Linux Linux unaffected 6.18.51 6.18.* semver Not specified
CNA Linux Linux unaffected 7.2.5 7.2.* semver Not specified
CNA Linux Linux unaffected 7.3-rc2 * original_commit_for_fix Not specified

References

ReferenceSourceLinkTags
git.kernel.org/stable/c/056ef8e6700b8b6ca11453a9d4bfb1b868a5cd88 416baaa9-dc9f-4396-8d5f-8c081fb06d67 git.kernel.org
git.kernel.org/stable/c/48934c2927414a37a7fadeb6091113177c0b2038 416baaa9-dc9f-4396-8d5f-8c081fb06d67 git.kernel.org
git.kernel.org/stable/c/a8be8bbf0952bb7ff46636ead1896769c381fe55 416baaa9-dc9f-4396-8d5f-8c081fb06d67 git.kernel.org
git.kernel.org/stable/c/ab2958e0c94edd63315dd14dc548874cc63a4043 416baaa9-dc9f-4396-8d5f-8c081fb06d67 git.kernel.org
git.kernel.org/stable/c/183da103022ec11af55ba9951d2cc171fb6c836b 416baaa9-dc9f-4396-8d5f-8c081fb06d67 git.kernel.org
git.kernel.org/stable/c/4956993bb3befdf791d71a4952d8d13bcfd44c7b 416baaa9-dc9f-4396-8d5f-8c081fb06d67 git.kernel.org
git.kernel.org/stable/c/f4cb9c4556dcb593e66dbb855179dbd351dbb053 416baaa9-dc9f-4396-8d5f-8c081fb06d67 git.kernel.org
git.kernel.org/stable/c/fba600d824597b2a894ecae72fc422c2b8c08f8c 416baaa9-dc9f-4396-8d5f-8c081fb06d67 git.kernel.org
CVE Program record CVE.ORG www.cve.org canonical
NVD vulnerability detail NVD nvd.nist.gov canonical, analysis

© CVE.report 2026

Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties, implied or otherwise, with regard to this information or its use. Any use of this information is at the user's risk. It is the responsibility of user to evaluate the accuracy, completeness or usefulness of any information, opinion, advice or other content. EACH USER WILL BE SOLELY RESPONSIBLE FOR ANY consequences of his or her direct or indirect use of this web site. ALL WARRANTIES OF ANY KIND ARE EXPRESSLY DISCLAIMED. This site will NOT BE LIABLE FOR ANY DIRECT, INDIRECT or any other kind of loss.

CVE, CWE, and OVAL are registred trademarks of The MITRE Corporation and the authoritative source of CVE content is MITRE's CVE web site. This site includes MITRE data granted under the following license.

Free CVE JSON API cve.report/api

CVE.report and Source URL Uptime Status status.cve.report