CVE-2026-90000— Linux内核 rmi驱动 RMI报告过小OOB访问
一分钟漏洞结论
影响对象
Linux Linux
利用判断
尚无明确在野利用证据，仍需结合暴露面评估
建议动作
优先检查厂商安全公告和参考链接中的修复版本；无法立即升级时，限制受影响服务暴露并加强监测。
在 Linux 内核中，已修复以下漏洞： HID: rmi：修复尺寸过小的 RMI 报告导致的越界访问（OOB）问题 驱动程序完全依据设备提供的报告描述符来确定 / 缓冲区的大小，且没有设置最小边界： 然而，该驱动随后以固定偏移量对该缓冲区进行读写操作。如果一个设备声明了 1 字节的输出报告和 1 字节的输入报告， 对两者各返回 2（可能包含报告 ID 等开销），因此 为 4。但 （在探测阶段通过 无条件调用）会写入 ，而 会写入 。由于 位于 处，这些写入操作会破坏下一个响应解析所依赖的内存区域。 读路径问题更为
可能的 ATT&CK 技术 1 AI
T1190 · Exploit Public-Facing Application影响版本矩阵 18
| 厂商 | 产品 | 版本范围 | 状态 |
|---|---|---|---|
| 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 条更多 | |||
获取后续新漏洞提醒
登录后订阅
一、 漏洞 CVE-2026-90000 基础信息
漏洞信息
对漏洞内容有疑问？看看神龙的深度分析是否有帮助！
查看神龙十问 ↗
尽管我们使用了先进的大模型技术，但其输出仍可能包含不准确或过时的信息。神龙努力确保数据的准确性，但请您根据实际情况进行核实和判断。
Vulnerability Title
HID: rmi: fix OOB access with undersized RMI reports
来源: 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---
来源: 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
来源: CVE Program / CVE List V5
Vulnerability Type
N/A
来源: CVE Program / CVE List V5
受影响产品
二、漏洞 CVE-2026-90000 的公开POC
| # | POC 描述 | 源链接 | 神龙链接 |
|---|
AI 生成 POC
高级
未找到公开 POC。
登录以生成 AI POC三、漏洞 CVE-2026-90000 的情报信息
请登录查看更多情报信息。
CVE-2026-90000 其他参考 (8)
同批安全公告 · Linux · 2026-09-16 · 共 276 条
| CVE-2026-90048 | 9.8 CRITICAL | Linux内核NTFS3文件系统越界写漏洞 |
| CVE-2026-90012 | 9.8 CRITICAL | SPI DMA映射所有权修复 |
| CVE-2026-89857 | 9.8 CRITICAL | QLogic qla2xxx NVMe LS拒绝竞态条件漏洞 |
| CVE-2026-89970 | 9.8 CRITICAL | NVM Target SQ拆除时超时工作未同步 |
| CVE-2026-89847 | 9.8 CRITICAL | qla2xxx SCSI驱动异步IOCB超时双重完成漏洞 |
| CVE-2026-89969 | 9.8 CRITICAL | Linux内核 nvmet-tcp 越界写入漏洞 |
| CVE-2026-89972 | 9.8 CRITICAL | NVMe驱动错误路径SRCU宽限期缺失漏洞 |
| CVE-2026-89990 | 9.8 CRITICAL | Ceph ceph_mds_check_access 互斥锁缺失漏洞 |
| CVE-2026-90036 | 9.8 CRITICAL | Linux NFSd 阻塞锁收割时释放后使用漏洞 |
| CVE-2026-90038 | 9.8 CRITICAL | Linux内核NFSD导出撤销后使用漏洞 |
| CVE-2026-90037 | 9.8 CRITICAL | Linux内核NFSD close_lru释放后使用漏洞 |
| CVE-2026-89788 | 9.8 CRITICAL | Linux kernel ksmbd 释放后使用漏洞 |
| CVE-2026-89783 | 9.8 CRITICAL | Linux内核 xfrm6 越界写入漏洞 |
| CVE-2026-90042 | 9.8 CRITICAL | Ceph 虚拟内存分配缓冲区文件名解密漏洞 |
| CVE-2026-89778 | 9.8 CRITICAL | isofs 空 zisofs 块页面数组越界访问漏洞 |
| CVE-2026-89914 | 9.3 CRITICAL | KVM arm64 虚拟地址符号扩展错误 |
| CVE-2026-89915 | 9.3 CRITICAL | KVM arm64 移除虚拟机级 VNCR 映射计数器 |
| CVE-2026-90049 | 9.3 CRITICAL | 内核网络子系统中skb_zerocopy处理中的缺陷 |
| CVE-2026-89775 | 9.3 CRITICAL | KVM arm64 VNCR TLB大小计算漏洞 |
| CVE-2026-89918 | 9.3 CRITICAL | KVM arm64 TLBI失效处理漏洞 |
显示前 20 条，共 276 条。 查看全部 → →
IV. Related Vulnerabilities
V. Comments for CVE-2026-90000
暂无评论