{"api_version":"1","generated_at":"2026-09-17T14:47:49+00:00","cve":"CVE-2026-90000","urls":{"html":"https://cve.report/CVE-2026-90000","api":"https://cve.report/api/cve/CVE-2026-90000.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-90000","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-90000"},"summary":{"title":"HID: rmi: fix OOB access with undersized RMI reports","description":"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->input_report_size  = hid_report_len(input_report);\n\tdata->output_report_size = hid_report_len(output_report);\n\talloc_size = data->output_report_size + data->input_report_size;\n\tdata->writeReport = devm_kzalloc(&hdev->dev, alloc_size, GFP_KERNEL);\n\tdata->readReport = data->writeReport + data->output_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&readReport[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 &writeReport[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->driver_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's life.\n\nClamping does not regress working hardware: the read loop already\nhandles\n---truncated---","state":"PUBLISHED","assigner":"Linux","published_at":"2026-09-16 11:17:11","updated_at":"2026-09-16 15:18:23"},"problem_types":[],"metrics":[{"version":"3.1","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","type":"Secondary","score":"8.8","severity":"HIGH","vector":"CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H","data":{"version":"3.1","vectorString":"CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H","baseScore":8.8,"baseSeverity":"HIGH","attackVector":"ADJACENT_NETWORK","attackComplexity":"LOW","privilegesRequired":"NONE","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"HIGH","integrityImpact":"HIGH","availabilityImpact":"HIGH"}},{"version":"3.1","source":"CNA","type":"DECLARED","score":"8.8","severity":"HIGH","vector":"CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H","data":{"baseScore":8.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H","version":"3.1"}}],"references":[{"url":"https://git.kernel.org/stable/c/056ef8e6700b8b6ca11453a9d4bfb1b868a5cd88","name":"https://git.kernel.org/stable/c/056ef8e6700b8b6ca11453a9d4bfb1b868a5cd88","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/48934c2927414a37a7fadeb6091113177c0b2038","name":"https://git.kernel.org/stable/c/48934c2927414a37a7fadeb6091113177c0b2038","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/a8be8bbf0952bb7ff46636ead1896769c381fe55","name":"https://git.kernel.org/stable/c/a8be8bbf0952bb7ff46636ead1896769c381fe55","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/ab2958e0c94edd63315dd14dc548874cc63a4043","name":"https://git.kernel.org/stable/c/ab2958e0c94edd63315dd14dc548874cc63a4043","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/183da103022ec11af55ba9951d2cc171fb6c836b","name":"https://git.kernel.org/stable/c/183da103022ec11af55ba9951d2cc171fb6c836b","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/4956993bb3befdf791d71a4952d8d13bcfd44c7b","name":"https://git.kernel.org/stable/c/4956993bb3befdf791d71a4952d8d13bcfd44c7b","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/f4cb9c4556dcb593e66dbb855179dbd351dbb053","name":"https://git.kernel.org/stable/c/f4cb9c4556dcb593e66dbb855179dbd351dbb053","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/fba600d824597b2a894ecae72fc422c2b8c08f8c","name":"https://git.kernel.org/stable/c/fba600d824597b2a894ecae72fc422c2b8c08f8c","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-90000","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-90000","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 9fb6bf02e3ad04c20edb8e46536ce3eeda32c736 fba600d824597b2a894ecae72fc422c2b8c08f8c git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 9fb6bf02e3ad04c20edb8e46536ce3eeda32c736 056ef8e6700b8b6ca11453a9d4bfb1b868a5cd88 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 9fb6bf02e3ad04c20edb8e46536ce3eeda32c736 183da103022ec11af55ba9951d2cc171fb6c836b git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 9fb6bf02e3ad04c20edb8e46536ce3eeda32c736 a8be8bbf0952bb7ff46636ead1896769c381fe55 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 9fb6bf02e3ad04c20edb8e46536ce3eeda32c736 ab2958e0c94edd63315dd14dc548874cc63a4043 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 9fb6bf02e3ad04c20edb8e46536ce3eeda32c736 f4cb9c4556dcb593e66dbb855179dbd351dbb053 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 9fb6bf02e3ad04c20edb8e46536ce3eeda32c736 48934c2927414a37a7fadeb6091113177c0b2038 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 9fb6bf02e3ad04c20edb8e46536ce3eeda32c736 4956993bb3befdf791d71a4952d8d13bcfd44c7b git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 3.16","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 3.16 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 5.10.270 5.10.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 5.15.221 5.15.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.1.188 6.1.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.6.157 6.6.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.12.110 6.12.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.18.51 6.18.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.2.5 7.2.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.3-rc2 * original_commit_for_fix","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":null,"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"defaultStatus":"unaffected","product":"Linux","programFiles":["drivers/hid/hid-rmi.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"lessThan":"fba600d824597b2a894ecae72fc422c2b8c08f8c","status":"affected","version":"9fb6bf02e3ad04c20edb8e46536ce3eeda32c736","versionType":"git"},{"lessThan":"056ef8e6700b8b6ca11453a9d4bfb1b868a5cd88","status":"affected","version":"9fb6bf02e3ad04c20edb8e46536ce3eeda32c736","versionType":"git"},{"lessThan":"183da103022ec11af55ba9951d2cc171fb6c836b","status":"affected","version":"9fb6bf02e3ad04c20edb8e46536ce3eeda32c736","versionType":"git"},{"lessThan":"a8be8bbf0952bb7ff46636ead1896769c381fe55","status":"affected","version":"9fb6bf02e3ad04c20edb8e46536ce3eeda32c736","versionType":"git"},{"lessThan":"ab2958e0c94edd63315dd14dc548874cc63a4043","status":"affected","version":"9fb6bf02e3ad04c20edb8e46536ce3eeda32c736","versionType":"git"},{"lessThan":"f4cb9c4556dcb593e66dbb855179dbd351dbb053","status":"affected","version":"9fb6bf02e3ad04c20edb8e46536ce3eeda32c736","versionType":"git"},{"lessThan":"48934c2927414a37a7fadeb6091113177c0b2038","status":"affected","version":"9fb6bf02e3ad04c20edb8e46536ce3eeda32c736","versionType":"git"},{"lessThan":"4956993bb3befdf791d71a4952d8d13bcfd44c7b","status":"affected","version":"9fb6bf02e3ad04c20edb8e46536ce3eeda32c736","versionType":"git"}]},{"defaultStatus":"affected","product":"Linux","programFiles":["drivers/hid/hid-rmi.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"status":"affected","version":"3.16"},{"lessThan":"3.16","status":"unaffected","version":"0","versionType":"semver"},{"lessThanOrEqual":"5.10.*","status":"unaffected","version":"5.10.270","versionType":"semver"},{"lessThanOrEqual":"5.15.*","status":"unaffected","version":"5.15.221","versionType":"semver"},{"lessThanOrEqual":"6.1.*","status":"unaffected","version":"6.1.188","versionType":"semver"},{"lessThanOrEqual":"6.6.*","status":"unaffected","version":"6.6.157","versionType":"semver"},{"lessThanOrEqual":"6.12.*","status":"unaffected","version":"6.12.110","versionType":"semver"},{"lessThanOrEqual":"6.18.*","status":"unaffected","version":"6.18.51","versionType":"semver"},{"lessThanOrEqual":"7.2.*","status":"unaffected","version":"7.2.5","versionType":"semver"},{"lessThanOrEqual":"*","status":"unaffected","version":"7.3-rc2","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"cpeMatch":[{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"5.10.270","versionStartIncluding":"3.16","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"5.15.221","versionStartIncluding":"3.16","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.1.188","versionStartIncluding":"3.16","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.6.157","versionStartIncluding":"3.16","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.12.110","versionStartIncluding":"3.16","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.18.51","versionStartIncluding":"3.16","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.2.5","versionStartIncluding":"3.16","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.3-rc2","versionStartIncluding":"3.16","vulnerable":true}],"negate":false,"operator":"OR"}]}],"descriptions":[{"lang":"en","value":"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->input_report_size  = hid_report_len(input_report);\n\tdata->output_report_size = hid_report_len(output_report);\n\talloc_size = data->output_report_size + data->input_report_size;\n\tdata->writeReport = devm_kzalloc(&hdev->dev, alloc_size, GFP_KERNEL);\n\tdata->readReport = data->writeReport + data->output_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&readReport[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 &writeReport[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->driver_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's life.\n\nClamping does not regress working hardware: the read loop already\nhandles\n---truncated---"}],"metrics":[{"cvssV3_1":{"baseScore":8.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H","version":"3.1"},"scenarios":[{"lang":"en","value":"AV:A - hid-rmi matches HID_DEVICE(HID_BUS_ANY, HID_GROUP_RMI, HID_ANY_ID, HID_ANY_ID), so a Bluetooth HID/HoGP peripheral claiming Synaptics VID 0x06cb and an RMI-style descriptor is grouped HID_GROUP_RMI and bound over an adjacent wireless link; USB attach is only a lower-severity physical path.\nAC:L - The attacker fully controls the HID report descriptor (undersized input/output reports) and RMI reply bytes, including the read-length byte and PDT interrupt-source counts, so probe performs the OOB read/write and optional zero-length hang with no race or other condition outside attacker control.\nPR:N - A malicious HID peripheral is sufficient: hid-rmi autoloads and rmi_input_configured()/rmi_f01_probe() run during enumeration, with no local account, capability, or init-namespace privilege required on the victim.\nUI:N - rmi_set_page() and rmi_hid_read_block() run from rmi_input_configured() during hid_hw_start() as soon as the device connects or auto-reconnects; no extra victim open, mount, or confirmation is required.\nS:U - The heap out-of-bounds read and write corrupt host kernel memory in the HID/RMI probe path and do not cross a VM, IOMMU, or other separate security authority.\nC:H - rmi_hid_read_block() copies from &readReport[2] using a device-supplied length of up to 255 bytes with no input_report_size bound, reading adjacent slab into RMI registers that are logged and exported via the world-readable product_id sysfs attribute; heap OOB reads are High confidentiality.\nI:H - Undersized output reports make rmi_set_page() and rmi_hid_read_block() store past writeReport, and rmi_hid_write_block() memcpy's an unbounded PDT-derived length to &writeReport[4], overflowing the heap allocation; out-of-bounds writes are High integrity.\nA:H - The heap OOB access causes a kernel oops (KASAN slab-out-of-bounds in rmi_hid_read_block/rmi_hid_write_block), and a device answering zero-length read replies loops forever in probe with page_mutex held, hanging a kworker; kernel crash or hang is High availability."}]}],"providerMetadata":{"dateUpdated":"2026-09-16T14:41:16.030Z","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux"},"references":[{"url":"https://git.kernel.org/stable/c/fba600d824597b2a894ecae72fc422c2b8c08f8c"},{"url":"https://git.kernel.org/stable/c/056ef8e6700b8b6ca11453a9d4bfb1b868a5cd88"},{"url":"https://git.kernel.org/stable/c/183da103022ec11af55ba9951d2cc171fb6c836b"},{"url":"https://git.kernel.org/stable/c/a8be8bbf0952bb7ff46636ead1896769c381fe55"},{"url":"https://git.kernel.org/stable/c/ab2958e0c94edd63315dd14dc548874cc63a4043"},{"url":"https://git.kernel.org/stable/c/f4cb9c4556dcb593e66dbb855179dbd351dbb053"},{"url":"https://git.kernel.org/stable/c/48934c2927414a37a7fadeb6091113177c0b2038"},{"url":"https://git.kernel.org/stable/c/4956993bb3befdf791d71a4952d8d13bcfd44c7b"}],"title":"HID: rmi: fix OOB access with undersized RMI reports","x_generator":{"engine":"bippy-1.2.0"}}},"cveMetadata":{"assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","assignerShortName":"Linux","cveId":"CVE-2026-90000","datePublished":"2026-09-16T10:33:11.380Z","dateReserved":"2026-09-11T19:38:34.780Z","dateUpdated":"2026-09-16T14:41:16.030Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-09-16 11:17:11","lastModifiedDate":"2026-09-16 15:18:23","problem_types":[],"metrics":{"cvssMetricV31":[{"source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","type":"Secondary","cvssData":{"version":"3.1","vectorString":"CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H","baseScore":8.8,"baseSeverity":"HIGH","attackVector":"ADJACENT_NETWORK","attackComplexity":"LOW","privilegesRequired":"NONE","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"HIGH","integrityImpact":"HIGH","availabilityImpact":"HIGH"},"exploitabilityScore":2.8,"impactScore":5.9}]},"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"90000","Ordinal":"1","Title":"HID: rmi: fix OOB access with undersized RMI reports","CVE":"CVE-2026-90000","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"90000","Ordinal":"1","NoteData":"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->input_report_size  = hid_report_len(input_report);\n\tdata->output_report_size = hid_report_len(output_report);\n\talloc_size = data->output_report_size + data->input_report_size;\n\tdata->writeReport = devm_kzalloc(&hdev->dev, alloc_size, GFP_KERNEL);\n\tdata->readReport = data->writeReport + data->output_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&readReport[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 &writeReport[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->driver_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's life.\n\nClamping does not regress working hardware: the read loop already\nhandles\n---truncated---","Type":"Description","Title":"HID: rmi: fix OOB access with undersized RMI reports"}]}}}