[CVE-2026-90000][MODERATE 7.0] HID: rmi: fix OOB access with undersized RMI reports

[AL-KERNEL <alkernel@kernelcve.org>]

CVE: CVE-2026-90000
Priority: MODERATE 7.0
AL-KERNEL base severity: MODERATE
KPANIC flag: YES
Patch: HID: rmi: fix OOB access with undersized RMI reports
Commit: fba600d824597b2a894ecae72fc422c2b8c08f8c
Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=fba600d824597b2a894ecae72fc422c2b8c08f8c
Original CVE announcement: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-90000
Analysis date: Wed, 16 Sep 2026 10:28:54 -0400
ActionableScore: 7
ActionableScore lower bound: 6
Actionable bucket: Strong Important candidate
Manual review required: YES

Summary:
No one-sentence report phrase was found.

======================================================================
ABOUT THIS REPORT
======================================================================

The original Linux kernel CVE announcement for CVE-2026-90000 is available here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-90000

The original announcement does not normally provide a security severity
estimate, CVSS assessment, or enough information to determine whether the
reported kernel bug represents a practically relevant security issue.

This report was generated by AL-KERNEL, an AI-assisted Linux kernel
vulnerability analysis system developed by Alexander Larkin. It combines
an autonomous classifier with LLM-assisted technical analysis and a
separate ActionableScore mechanism.

The purpose of this report is to prioritize Linux kernel CVEs before
manual review, identify cases that require prompt investigation, and
support automatic closure of issues that are unlikely to have meaningful
security impact.

Published priority for this report: MODERATE 7.0
Manual review required: YES

A detailed explanation of the methodology and priority rules is included
at the end of this message.

======================================================================
AL-KERNEL CLASSIFICATION RESULT
======================================================================

CVE-2026-90000	MODERATE	https://www.kernelcve.org/list/?q=CVE-2026-90000 CHECK WITH IMPACT FROM ORIG NN LOW	Maybe valid. Check manually. Hints by AL-KERNEL: The best (paranoid) CVSS is 'AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H';*CWE-787;CWE-125;*CWE-835;Other CVSS 'AV:P/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H';BEST CVSS score: '7.8';DESCR 'An out-of-bounds access in the HID/RMI driver occurs because report buffer sizes are taken from the device supplied HID report descriptor while the driver later uses fixed offsets and device controlled lengths. A malicious RMI HID device can declare undersized input or output reports and trigger OOB reads, OOB writes, heap data exposure through product id handling and sysfs, or a stuck probe worker via zero length replies. For the CVSS the PR:L is used for the higher paranoid local software trigger path because a local user or service with access to /dev/uhid or a USB gadget interface may emulate the device without full host administration. The issue is not network reachable and normally requires physical device attachment or local device emulation access. Impact is at least denial of service and information disclosure, and in worst case may allow privilege escalation because the patch context shows both OOB read and OOB write primitives in kernel memory.';YES REQUIRES MANUAL CHECK; ,and ActionableScore result is Strong Important candidate (with actual score 7)	YES	READ KASAN OOB USB INIT LEAK ERRORPATH HARDWARE LINUS TEST  KPANIC INCREASED_TO_MODERATE7_FROM_LOW_BASED_ON_GUESSCVSS_AND_ACTIONABLESCOREHIGHER4 KPANIC INCREASED_TO_HIGH_BASED_ON_ACTIONABLESCOREHIGHERTHAN5 DECREASED_TO_MODERATE7_BASED_ON_FALSEPOSCHECKOFDH	NO	NO	checked

======================================================================
ACTIONABLESCORE ANALYSIS
======================================================================

ActionableScore=7
ActionableScoreLower=6
PrimitiveClass=CLASS_A
RealUAF=NO
HostAdminRequired=NO
NamespaceScopedPrivilege=NO
ImportantCandidate=YES
ManualReview=REQUIRED
AutoDowngradeAllowed=NO

1. ActionableScore

* Raw conservative score: 6
* Conservative score: 6. No floor or cap applied.
* Raw paranoid score: 7
* Paranoid score: 7. No floor or cap applied.
* Final recommended bucket: **Strong Important candidate**::

2. Signal breakdown

Positive conservative signals:

* +2 Strong corruption primitive. The patch establishes concrete slab out-of-bounds write paths in `rmi_set_page()` and `rmi_hid_write_block()`, driven by undersized HID/RMI report sizes and unbounded write length.
* +1 Confidentiality plausible and demonstrated. The OOB read bytes can become RMI register values, are printed as product id, exported through a mode 0444 sysfs attribute, and sent back to the device as interrupt mask data.
* +1 Reliable kernel crash or strong DoS. KASAN reports slab-out-of-bounds read and write, and the zero-length reply case can leave a probe worker stuck in D state.
* +1 Firmware/device-mediated external influence. A malicious HID/RMI device controls the report descriptor and reply data that drive the vulnerable parsing and copy lengths.
* +1 Memory layout invariant restoration. The fix restores consistency between declared report sizes, allocated buffer size, fixed offsets, and copy lengths across read and write report handling.

Additional paranoid signal:

* +1 Below-host-admin local emulation exposure. The supplied context reports reproduction through `/dev/uhid` and dummy_hcd plus raw-gadget, so a local user or service with such device-emulation access may trigger the same kernel paths without full host administration.

Important non-awarded signals:

* RealUAF not awarded. The primitive is OOB read/write and stuck loop behavior, not post-free object use.
* Controlled reclaim not demonstrated.
* Arbitrary kernel read/write not demonstrated.
* Direct network reachability not established.
* Concrete repeated release/refcount mutation not present.
* Extra Availability not awarded because the crash/hang impact is already counted once.
* Strong LPE +2 not separately awarded because privilege escalation is plausible from kernel OOB write, but no controlled target, controlled reclaim, callback hijack, credential overwrite, or demonstrated LPE chain is supplied.

3. Reachability analysis

The clearest attacker model is a malicious or emulated HID/RMI device. A physical attacker can present a crafted RMI HID device with undersized input/output reports and controlled replies. That does not require host administrator privilege on the victim, but it does require physical attachment or an equivalent device-emulation path.

The supplied context also reports reproduction via `/dev/uhid` and raw-gadget. Those paths may be available to a local user, a test service, a container with delegated device access, or a partially privileged device-management context depending on deployment. This supports the paranoid below-host-admin local trigger, but it is not treated as ordinary unprivileged reachability for all systems.

There is no evidence of direct network triggering. Namespace-scoped privilege is not relevant here. No race is required. The issue is input-driven during device probe and RMI report processing. HID/RMI hardware is device-specific, but the attack can be performed by emulation, so a rare-hardware-only penalty is not applied.

4. Primitive and severity interpretation

The exact primitive is attacker-influenced out-of-bounds access in `drivers/hid/hid-rmi.c`. The driver allocates `writeReport` and `readReport` according to device-supplied report lengths, but later uses fixed offsets and device-controlled lengths without ensuring the buffers are large enough.

This is not a UAF and not a repeated-release/refcount case. It is also not merely a device-local warning. The patch context demonstrates slab OOB read, slab OOB write, heap information disclosure to unprivileged userspace and the device, and a probe-worker hang.

PrimitiveClass is CLASS_A because a concrete kernel OOB write is established and the input controlling report sizes and copy lengths is attacker-influenced through the HID/RMI device. The demonstrated consequence includes DoS and information disclosure. The speculative consequence is local privilege escalation from kernel memory corruption, but that stronger outcome is not proven by the supplied evidence.

ImportantCandidate is YES because concrete OOB write plus disclosure is an Important-preserving primitive requiring security review. AutoDowngradeAllowed is NO because automatic closure would discard a real kernel corruption and disclosure primitive with unresolved exploitation leverage.

Likely operational severity is Strong Important candidate for environments where untrusted HID devices, `/dev/uhid`, USB gadget emulation, or delegated device-emulation access are realistic. It is lower in tightly controlled physical-access environments, but still not safe to auto-close.

5. One-sentence report phrase

A malicious or emulated HID/RMI device can declare undersized reports and trigger kernel OOB read/write, heap data disclosure through sysfs or device-visible data, and denial of service, with possible privilege-escalation relevance requiring manual review.

6. Manual review recommendation

MANUAL CHECK REQUIRED

Reason: concrete kernel slab OOB read and OOB write are established, and the read path has an explicit heap disclosure channel to unprivileged userspace and to the device.

7. Call-site confidence

Call-site confidence: high

======================================================================
UPSTREAM PATCH SUMMARY
======================================================================

Patch: HID: rmi: fix OOB access with undersized RMI reports
Commit: fba600d824597b2a894ecae72fc422c2b8c08f8c
Upstream URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=fba600d824597b2a894ecae72fc422c2b8c08f8c

Commit description:

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 a reply carrying fewer bytes than requested, and a write longer
than the output report was overrunning the buffer already.

Verified on v6.12.69 and on v6.12.105 built with CONFIG_KASAN=y and
booted kasan_multi_shot, whose hid-rmi.c is identical to mainline here.
An emulated RMI4 device driven over /dev/uhid, and the same device again
over dummy_hcd plus raw-gadget, give identical results:

  BUG: KASAN: slab-out-of-bounds in rmi_hid_read_block+0x409/0x750 [hid_rmi]
  Read of size 21 at addr ffff88800bf33bba by task kworker/0:3/285
   __asan_memcpy+0x23/0x60
   rmi_hid_read_block+0x409/0x750 [hid_rmi]
   rmi_f01_probe+0x5dd/0x1dc0 [rmi_core]

[Commit description truncated; see the upstream URL below]

Changed files:
  drivers/hid/hid-rmi.c

Diff excerpt:

Not included in this email. See the upstream URL for the full patch.

Full patch:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=fba600d824597b2a894ecae72fc422c2b8c08f8c

======================================================================
DETAILED REPORT METHODOLOGY
======================================================================

The original Linux kernel CVE announcement for CVE-2026-90000 can be found here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-90000

The original CVE announcement normally does not include a security-level
estimate. In particular, it may not contain a CVSS assessment, an impact
level, or enough information to determine whether the reported bug is a
practically relevant security issue. One purpose of this parallel CVE list
is to provide that missing technical and prioritization information.

The original goal of the AL-KERNEL project was to prioritize Linux kernel
CVE analysis automatically before manual review. The system can also help
identify non-security issues that may be suitable for automatic closure.

This report was generated by AL-KERNEL, an AI-assisted Linux kernel
vulnerability analysis system developed by Alexander Larkin.

The first analysis stage combines an autonomous classifier with additional
LLM-based analysis. The autonomous classifier runs locally on a CPU and is
based on a backpropagation neural network. Together, these mechanisms
produce a technical vulnerability description, identify likely weakness
types, estimate CVSS severity, and provide input for ActionableScore.

Two CVSS estimates are retained because incomplete kernel vulnerability
information often permits more than one defensible interpretation:

  Conservative CVSS vector: AV:P/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H
  The Best / paranoid CVSS vector: AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
  The Best / paranoid CVSS score: 7.8

The conservative vector represents a lower-impact interpretation.
The Best/paranoid vector intentionally represents a plausible upper-bound
interpretation and should not automatically be treated as demonstrated
real-world impact.

CVSS may also need to be adjusted for a particular Linux deployment,
because actual reachability, privileges, enabled kernel configuration,
hardware, namespaces, exposed device nodes, and other environmental
conditions can differ significantly between systems.

A separate ActionableScore mechanism evaluates practical remediation
urgency. Its analysis may include reachability, attack prerequisites,
subsystem exposure, memory-corruption characteristics, denial-of-service
reliability, and possible confidentiality, integrity, or
privilege-escalation impact.

  Conservative ActionableScore: 6
  Paranoid ActionableScore: 7

The final base severity is taken directly from the second tab-separated
field of the AL-KERNEL classification result. ActionableScore does not
replace or independently override that final AL-KERNEL decision, and
if ActionableScore adjusted impact level of ALKERNEL, then you would see
self-readable flags above like INCREASED_TO_HIGH_BASED_ON_ACTIONABLESCOREHIGHEREQTHAN7.

For an AL-KERNEL result of MODERATE, this report uses the following
additional presentation split:

  ActionableScore below 5   -> MODERATE REGULAR
  ActionableScore 5 or more -> MODERATE 7.0

The distinction between MODERATE REGULAR and MODERATE 7.0 makes it
possible to identify Moderate issues that should receive manual analysis
and fixes before lower-priority MODERATE REGULAR issues. In many cases,
MODERATE REGULAR fixes may wait for a later rebase or routine update.

There is one override in which MODERATE REGULAR becomes MODERATE 7.0
even when the ActionableScore is below 5. When the AL-KERNEL result
contains the KPANIC flag, a MODERATE result is always presented as
MODERATE 7.0. The KPANIC flag selected with few regexps without
usage of AI at all, so it helps to detect cases when Kernel Crash happens
and similar (to filter False-Negative results from the LLM usage).

KPANIC indicates that a reliable kernel crash, kernel panic, or similarly
serious kernel availability impact was identified by the classification
workflow.

AL-KERNEL base severity for this report: MODERATE
KPANIC detected for this report: YES
Published priority for this report (same as in Subject): MODERATE 7.0

These results are intended to support engineering triage. They are
machine-generated estimates, and cases marked for manual review should
be validated by a human security engineer before final disposition.
For more info read docs linked from here: https://kernelcve.org/
(and you can submit you own patch there to generate such a report
for non-existant CVE-id yet).

Note that in many cases this AI tool selects higher severity, than
real is (means you can expect Importants instead of Moderate 7.0 or
Moderates 7.0 instead of regular Moderates). If you see such cases,
please use reply email interface to add additional manual analyses
info to this particular CVE.
And please, please, let me know when you see Lows instead of Importants
or Important instead of Low (because particular for such cases I
need to tune this AI tool to make it better for this one and next similar).
My contact email for such notifications is alexanjelausa@gmail.com (and both
send reply to CVE record itself too and see "reply" button below for howto reply).