GHSA-Q6XG-4CV5-FXHC
Vulnerability from github – Published: 2026-09-16 12:30 – Updated: 2026-09-16 15:31In 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---
{
"affected": [],
"aliases": [
"CVE-2026-90000"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-16T11:17:11Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nHID: rmi: fix OOB access with undersized RMI reports\n\nThe hid-rmi driver sizes its writeReport/readReport buffer purely from\nthe report descriptor supplied by the device, with no minimum bound:\n\n\tdata-\u003einput_report_size = hid_report_len(input_report);\n\tdata-\u003eoutput_report_size = hid_report_len(output_report);\n\talloc_size = data-\u003eoutput_report_size + data-\u003einput_report_size;\n\tdata-\u003ewriteReport = devm_kzalloc(\u0026hdev-\u003edev, alloc_size, GFP_KERNEL);\n\tdata-\u003ereadReport = data-\u003ewriteReport + data-\u003eoutput_report_size;\n\nbut then reads and writes fixed offsets into it. A device declaring a\n1-byte output and a 1-byte input report makes hid_report_len() return 2\nfor each, so alloc_size is 4, while rmi_set_page() -- reached\nunconditionally at probe time through rmi_input_configured() -- stores\nwriteReport[4] and rmi_hid_read_block() stores writeReport[0..5]. Since\nreadReport lives at writeReport + output_report_size, those stores also\ncorrupt the window the next reply is parsed out of.\n\nThe read path is worse: the copy length comes from readReport[1], which\nthe device fills in and can be up to 255, and the copy starts at\n\u0026readReport[2] with no regard for input_report_size, so it runs past the\nend of the allocation into adjacent slab objects. This does not even\nneed a lying device -- rmi_f01_probe() issues a fixed 21-byte register\nread, so any device declaring an input report smaller than 23 bytes\nreads out of bounds even when it answers truthfully. Those bytes become\nthe register values the RMI core acts on: rmi_f01_probe() prints them to\nthe kernel log as the product id and exports them through the mode 0444\nsysfs attribute of the same name, and rmi_driver_set_irq_bits() sends\nthem back to the device as the interrupt mask, so an undersized report\ndescriptor leaks heap contents both to unprivileged userspace and to the\ndevice itself.\n\nThe write path has no bound either: rmi_hid_write_block() copies an\nunbounded len to \u0026writeReport[4], and the largest caller a device can\ndrive at probe time is rmi_driver_set_irq_bits(), whose length is\nderived from the interrupt source counts the device declares in its Page\nDescription Table.\n\nFinally, the read loop cannot terminate on a zero-length reply: such a\nreply copies nothing and advances neither bytes_read nor bytes_needed,\nand because a reply did arrive the one second wait_event_timeout() does\nnot fire either, so a device answering 0 forever keeps the loop running\ninside the probe worker with page_mutex held. khungtaskd does not\nnotice, because every reply wakes the task.\n\nReject reports too small for what the driver builds -- 6 output bytes\nfor the write reports and 3 input bytes for the read handshake -- at\nprobe time, clamp the write and the read copy to the report sizes the\ndevice declared, and treat a zero-length reply as an error. A device\nrefused this way is started as an ordinary HID device, like one that\ndoes not carry the RMI report ids at all.\n\nRMI_DEVICE must not be left set in device_flags on that path, because\nrmi_input_configured() would then run the RMI setup and reach\nrmi_set_page(), which writes the writeReport buffer the refusal just\nskipped allocating. The bit can arrive set: rmi_probe() copies\nid-\u003edriver_data into device_flags before the report checks, and a bind\nthrough the new_id sysfs attribute can supply driver_data with\nRMI_DEVICE (BIT(0)) set. Strip the bit where driver_data is copied, so\nRMI_DEVICE keeps meaning exactly \"this probe validated the reports\"; the\nthree jumps to start that predate this patch are covered as well.\n\nThe error path also clears RMI_READ_DATA_PENDING on its way out, because\nthat flag is what the wait at the top of the loop tests: leaving it set\nwould make every later wait_event_timeout() return immediately on the\nstale reply and kill the read path for the rest of the device\u0027s life.\n\nClamping does not regress working hardware: the read loop already\nhandles\n---truncated---",
"id": "GHSA-q6xg-4cv5-fxhc",
"modified": "2026-09-16T15:31:06Z",
"published": "2026-09-16T12:30:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-90000"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/056ef8e6700b8b6ca11453a9d4bfb1b868a5cd88"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/183da103022ec11af55ba9951d2cc171fb6c836b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/48934c2927414a37a7fadeb6091113177c0b2038"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4956993bb3befdf791d71a4952d8d13bcfd44c7b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a8be8bbf0952bb7ff46636ead1896769c381fe55"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ab2958e0c94edd63315dd14dc548874cc63a4043"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f4cb9c4556dcb593e66dbb855179dbd351dbb053"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fba600d824597b2a894ecae72fc422c2b8c08f8c"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.