CVE Intelligence
High

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->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---

Published Sep 16, 2026 · Updated Oct 15, 2026 · Sources: NIST National Vulnerability Database, CVE Program (cve.org) e CISA ADP · CNA: Linux

Who exploits it and how urgent it is

A 0–100 score combining confirmed exploitation, ransomware and APT use, public exploits, EPSS and severity.

No exploitation signal in the sources consulted so far.
How the score was calculated
  • Technical severity (high)+6

The score orders the patch queue; it does not replace your asset context (internet exposure, criticality, compensating controls).

Triage

Is it exploited, how likely is exploitation, what does it touch, and how severe do the sources call it.

Exploitation
Not confirmed
Not in CISA KEV — an absence of record, not proof it is unexploited.
EPSS FIRST
—
No EPSS score.
Affects
Linux
Linux
CVSS base
8.8
High · 2 source(s)

Remediation

Fixes and mitigations documented by the sources — linked to the original advisory.

No fix documented by the sources we poll. That does not mean none exists: check the vendor advisory.

First 24 hours

Ordered from the record’s own fields — exposure first, because you cannot patch what you have not found. A rule-generated starting point.

  1. Identify exposed assets running the affected vendor/product/version combinations (Linux Linux).
  2. No fix documented in the sources: reduce exposure and monitor the vendor advisory.
  3. Search available logs for exploit probes, errors and authentication anomalies.

Affected scope

Vendor, product and versions as the sources word them.

VendorProductVersionsStatusSource
Linux Linux ≥ 9fb6bf02e3ad04c20edb8e46536ce3eeda32c736 and < fba600d824597b2a894ecae72fc422c2b8c08f8c≥ 9fb6bf02e3ad04c20edb8e46536ce3eeda32c736 and < 056ef8e6700b8b6ca11453a9d4bfb1b868a5cd88≥ 9fb6bf02e3ad04c20edb8e46536ce3eeda32c736 and < 183da103022ec11af55ba9951d2cc171fb6c836b≥ 9fb6bf02e3ad04c20edb8e46536ce3eeda32c736 and < a8be8bbf0952bb7ff46636ead1896769c381fe55≥ 9fb6bf02e3ad04c20edb8e46536ce3eeda32c736 and < ab2958e0c94edd63315dd14dc548874cc63a4043≥ 9fb6bf02e3ad04c20edb8e46536ce3eeda32c736 and < f4cb9c4556dcb593e66dbb855179dbd351dbb053≥ 9fb6bf02e3ad04c20edb8e46536ce3eeda32c736 and < 48934c2927414a37a7fadeb6091113177c0b2038≥ 9fb6bf02e3ad04c20edb8e46536ce3eeda32c736 and < 4956993bb3befdf791d71a4952d8d13bcfd44c7b
and 1 more version 3.16
Vulnerable CVE Program (cve.org) e CISA ADP

Attack characteristics

The CVSS vector, decoded. It describes the attack, not your exposure to it.

Attack vector
Adjacent
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Every base score collected

Sources score independently and may disagree; each row says who scored it and under which version.

ScoreVersionSeverityExpl.ImpactScored by
8.8 CVSS 3.1 High 2.8 5.9 416baaa9-dc9f-4396-8d5f-8c081fb06d67 via NIST National Vulnerability Database
8.8 CVSS 3.1 High — — Linux via CVE Program (cve.org) e CISA ADP
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (score shown at the top: 416baaa9-dc9f-4396-8d5f-8c081fb06d67)

Detection

Read off the CVSS vector and the weakness class. Starting points, not tested rules.

  • Not enough vector or weakness data: use the affected application’s logs as a starting point.
application logs

Timeline

What happened to this CVE, newest first.

  • 2026
  • Affected products added · linux/linux
    Oct 15, 2026 · CVE Program (cve.org) e CISA ADP
  • Record published
    Oct 15, 2026
  • CVSS changed · 8.8
    Oct 15, 2026 · NIST National Vulnerability Database
  • Source status changed · → Received
    Oct 15, 2026 · NIST National Vulnerability Database
  • Record created in this database
    Oct 15, 2026 · NIST National Vulnerability Database
  • CVE published
    Sep 16, 2026 · Linux

Source activity

Repeated readings are counted rather than listed.

  • 1× Official description updated · Oct 15, 2026 – Oct 15, 2026

References

8 on the record

Elsewhere on this site

Linux
every CVE for this vendor

Related CVEs (same products)

  • CVE-2026-99999 ipv4: validate checksum_start before completing checksum 13h
  • CVE-2026-98432 ipv4: free inet_opt and ireq_opt after an RCU grace period 13h
  • CVE-2026-98424 wifi: cfg80211: undo netns switch if renaming the wiphy fails 1d
  • CVE-2026-98425 wifi: mac80211: don't warn when an IBSS has no channel to scan 1d
  • CVE-2026-98426 wifi: mwifiex: fix IRQ leak using wrong index in MSI-X error path 1d
  • CVE-2026-98427 net/sched: codel: bound the dropping loop per dequeue call 1d

Not in any source we poll

Listed rather than left blank: an empty field and an unmeasured one look identical on screen, and only one is a reason to look elsewhere.

  • No FIRST EPSS score.
  • No fixed version, patch or mitigation documented.
  • No CISA SSVC assessment.
  • No CWE classification.
  • No confirmed IOCs, IP addresses, domains, file hashes, or malware artifacts supplied.
  • No organization-specific asset inventory, compensating-control status, or patch deployment evidence supplied.
  • No exploit packet captures, log samples, or incident case IDs supplied.

Answered from this record

Text assembled only from the fields above — no additional claims.

What should defenders know first?

CVE-2026-90000 is "HID: rmi: fix OOB access with undersized RMI reports", rated High. It affects Linux (Linux); versions are in the scope table. It is not in CISA KEV, which does not rule out exploitation. CVSS 8.8 describes technical severity. First verify whether exposed or business-critical assets run the affected versions, apply vendor fixes or mitigations, and preserve logs for review.

Comments

Moderated technical discussion. Read the community guidelines.

No comments yet.

Sign in or create an account to comment and suggest corrections.