Goal Reached Thanks to every supporter — we hit 100%!

Goal: 1000 CNY · Raised: 1359 CNY

100%
Buy Us a Coffee

CVE-2026-90000— HID: rmi: fix OOB access with undersized RMI reports

Quick assessment

Affected
Linux Linux
Exploitation
No confirmed in-the-wild exploitation; assess based on exposure
Recommended action
Check the vendor advisory and references for a fixed version. If immediate upgrade is impossible, restrict exposure and increase monitoring.

在 Linux 内核中，已修复以下漏洞： HID: rmi：修复尺寸过小的 RMI 报告导致的越界访问（OOB）问题 驱动程序完全依据设备提供的报告描述符来确定 / 缓冲区的大小，且没有设置最小边界： 然而，该驱动随后以固定偏移量对该缓冲区进行读写操作。如果一个设备声明了 1 字节的输出报告和 1 字节的输入报告， 对两者各返回 2（可能包含报告 ID 等开销），因此 为 4。但 （在探测阶段通过 无条件调用）会写入 ，而 会写入 。由于 位于 处，这些写入操作会破坏下一个响应解析所依赖的内存区域。 读路径问题更为

CVSS 8.8 · High EPSS 0.35% · P27

Possible ATT&CK Techniques 1 AI

T1190 · Exploit Public-Facing Application

Affected Version Matrix 18

VendorProduct Version RangeStatus
Linux Linux 9fb6bf02e3ad04c20edb8e46536ce3eeda32c736< fba600d824597b2a894ecae72fc422c2b8c08f8c affected
9fb6bf02e3ad04c20edb8e46536ce3eeda32c736< 056ef8e6700b8b6ca11453a9d4bfb1b868a5cd88 affected
9fb6bf02e3ad04c20edb8e46536ce3eeda32c736< 183da103022ec11af55ba9951d2cc171fb6c836b affected
9fb6bf02e3ad04c20edb8e46536ce3eeda32c736< a8be8bbf0952bb7ff46636ead1896769c381fe55 affected
9fb6bf02e3ad04c20edb8e46536ce3eeda32c736< ab2958e0c94edd63315dd14dc548874cc63a4043 affected
9fb6bf02e3ad04c20edb8e46536ce3eeda32c736< f4cb9c4556dcb593e66dbb855179dbd351dbb053 affected
9fb6bf02e3ad04c20edb8e46536ce3eeda32c736< 48934c2927414a37a7fadeb6091113177c0b2038 affected
9fb6bf02e3ad04c20edb8e46536ce3eeda32c736< 4956993bb3befdf791d71a4952d8d13bcfd44c7b affected
… +10 more rows
Get alerts for future matching vulnerabilities Log in to subscribe

I. Basic Information for CVE-2026-90000

Vulnerability Information
Have questions about the vulnerability? See if Shenlong's analysis helps!
View Shenlong Deep Dive ↗

Although we use advanced large model technology, its output may still contain inaccurate or outdated information.Shenlong tries to ensure data accuracy, but please verify and judge based on the actual situation.

Vulnerability Title
HID: rmi: fix OOB access with undersized RMI reports
Source: CVE Program / CVE List V5
Vulnerability Description
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---
Source: CVE Program / CVE List V5
CVSS Information
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Source: CVE Program / CVE List V5
Vulnerability Type
N/A
Source: CVE Program / CVE List V5

Affected Products

Vendor Product Affected Versions CPE Subscribe
Linux Linux 9fb6bf02e3ad04c20edb8e46536ce3eeda32c736 ~ fba600d824597b2a894ecae72fc422c2b8c08f8c -
Linux Linux 3.16 -

II. Public POCs for CVE-2026-90000

# POC Description Source Link Shenlong Link
AI-Generated POC Premium

No public POC found.

Login to generate AI POC

III. Intelligence Information for CVE-2026-90000

请登录查看更多情报信息。

Other References for CVE-2026-90000 (8)

Same Patch Batch · Linux · 2026-09-16 · 276 CVEs total

CVE-2026-90048 9.8 CRITICAL fs/ntfs3: fix slab-out-of-bounds write in ni_create_attr_list()
CVE-2026-90012 9.8 CRITICAL spi: Fix DMA mapping ownership on partial map failure
CVE-2026-89857 9.8 CRITICAL scsi: qla2xxx: Hold qpair lock when sending NVMe LS reject
CVE-2026-89970 9.8 CRITICAL nvmet-auth: Synchronize timeout work during SQ teardown
CVE-2026-89847 9.8 CRITICAL scsi: qla2xxx: Avoid double completion in async IOCB timeout
CVE-2026-89969 9.8 CRITICAL nvmet-tcp: fix out-of-bounds write when receiving an over-long PDU
CVE-2026-89972 9.8 CRITICAL nvme: add missing SRCU grace period in error path
CVE-2026-89990 9.8 CRITICAL ceph: lock mutex in ceph_mds_check_access()
CVE-2026-90036 9.8 CRITICAL NFSD: Prevent client use-after-free during blocked-lock reaping
CVE-2026-90038 9.8 CRITICAL NFSD: Prevent client use-after-free during export state revocation
CVE-2026-90037 9.8 CRITICAL NFSD: Prevent client use-after-free during close_lru reaping
CVE-2026-89788 9.8 CRITICAL ksmbd: fix tree connection use-after-free in smb2_tree_connect()
CVE-2026-89783 9.8 CRITICAL xfrm6: fix out-of-bounds write in xfrm6_input_addr() when secpath is full
CVE-2026-90042 9.8 CRITICAL ceph: properly decrypt filenames in vmalloc() buffers
CVE-2026-89778 9.8 CRITICAL isofs: fix out-of-bounds page array access on empty zisofs block
CVE-2026-89914 9.3 CRITICAL KVM: arm64: Sign-extend VA for range-based TLBI invalidation
CVE-2026-89915 9.3 CRITICAL KVM: arm64: Remove VM-wide VNCR mapping counter
CVE-2026-90049 9.3 CRITICAL net: skbuff: don't skb_tx_error() the source skb in skb_zerocopy()
CVE-2026-89775 9.3 CRITICAL KVM: arm64: Handle negative S1 walk levels in VNCR TLB size evaluation
CVE-2026-89918 9.3 CRITICAL KVM: arm64: Correctly handle end of VA space TLBI invalidation

Showing top 20 of 276 CVEs. View all on vendor page &rarr; →

IV. Related Vulnerabilities

Same product: Linux
Same vendor: Linux

V. Comments for CVE-2026-90000

No comments yet

Leave a comment