Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - HID： rmi：修正具有過小 RMI 報告的 OOB 存取 hid-rmi 驅動程式完全根據裝置提供的報告描述元調整其 writeReport/readReport 緩衝區的大小，沒有最小界限：
    資料>input_report_size = hid_report_len（input_report）;資料>output_report_size = hid_report_len（output_report）;alloc_size = 資料>output_report_size + 資料>input_report_size;
    data->writeReport = devm_kzalloc（&hdev->dev， alloc_size， GFP_KERNEL）;data->readReport = data->writeReport + data->output_report_size;但隨後讀取和寫入固定偏移量。宣告 1 位元組輸出和 1 位元組輸入報告的裝置會使 hid_report_len（） 每個返回 2，因此alloc_size為 4，而 rmi_set_page（） -- 在探測時透過 rmi_input_configured（） 無條件到達 -- 儲存 writeReport[4]，而 rmi_hid_read_block（） 儲存 writeReport[0..5]。由於 readReport 位於 writeReport + output_report_size，因此這些儲存區也會損毀下一個回覆剖析的視窗。讀取路徑更糟糕：副本長度來自 readReport[1]，設備填充該副本，最多可以是 255，並且副本從 &readReport[2] 開始，不考慮input_report_size，因此它會越過分配的末尾運行到相鄰的 slab 物件中。這甚至不需要一個躺著的裝置 -- rmi_f01_probe（） 發出固定的 21 位元組暫存器讀取，因此任何宣告小於 23 位元組的輸入報告的裝置即使如實回答，也會越界讀取。這些位元組成為 RMI 核心作用的暫存器值：
    rmi_f01_probe（） 將它們作為產品 ID 列印到核心記錄中，並透過同名的模式 0444 sysfs 屬性匯出它們，而 rmi_driver_set_irq_bits（） 將它們作為中斷遮罩發送回裝置，因此大小過小的報告描述元會將堆積內容洩漏到無權限的使用者空間和裝置本身。寫入路徑也沒有界限：rmi_hid_write_block（） 將不受限制的 len 複製到 &writeReport[4]，設備在探測時可以驅動的最大調用方是 rmi_driver_set_irq_bits（），其長度源自設備在其頁面描述表中聲明的中斷源計數。最後，讀取迴圈不能在零長度回覆上終止：這樣的回覆不複製任何內容，也不會bytes_read或bytes_needed，而且因為回覆確實到達了，一秒鐘的 wait_event_timeout（） 也不會觸發，因此回應 0 的裝置會永遠保持迴圈在探測工作程式內運行，並保留 page_mutex。khungtaskd 不會注意到，因為每個回覆都會喚醒任務。
    拒絕對於驅動程式所建置內容而言太小的報告 -- 寫入報告的 6 個輸出位元組和讀取交握的 3 個輸入位元組 -- 在探查時，將寫入和讀取複本限制為裝置宣告的報告大小，並將零長度回覆視為錯誤。以這種方式拒絕的裝置會作為普通 HID 裝置啟動，例如根本不攜帶 RMI 報告 ID 的裝置。RMI_DEVICE不得在該路徑上的 device_flags 中設定，因為 rmi_input_configured（） 隨後會執行 RMI 設定並到達 rmi_set_page（），這會寫入拒絕剛剛跳過配置的 writeReport 緩衝區。位元可以到達集合：rmi_probe（） 在報告檢查之前將 id->driver_data 複製到 device_flags，並且透過 new_id sysfs 屬性的綁定可以提供設定RMI_DEVICE （BIT（0）） 的driver_data。剝離複製driver_data的位，以便RMI_DEVICE保持確切的意思，此探查驗證了報告;也涵蓋了此補丁之前的三個跳躍開始。錯誤路徑也會清除RMI_READ_DATA_PENDING，因為該標誌是迴圈頂端的等待測試的內容：
    保持設定狀態會讓每個稍後的 wait_event_timeout（） 立即返回過時回覆，並在裝置的剩餘生命週期內終止讀取路徑。箝位不會回歸工作硬體：讀取迴圈已處理 ---truncated--- （CVE-2026-90000）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - HID：rmi：修复因尺寸过小的 RMI 报告而造成的 OOB 访问 hid-rmi 驱动程序完全根据设备提供的报告描述符来调整其 writeReport/readReport 缓冲区大小，没有最小边界：
    数据>input_report_size = hid_report_len（input_report）;数据>output_report_size = hid_report_len（output_report）;alloc_size = 数据>output_report_size + 数据>input_report_size;
    data->writeReport = devm_kzalloc（&hdev->dev， alloc_size， GFP_KERNEL）;data->readReport = data->writeReport + data->output_report_size;但随后会读取并写入固定偏移。声明 1 字节输出和 1 字节输入报告的设备会使 hid_report_len（） 为每个报告返回 2，因此 alloc_size 为 4，而 rmi_set_page（） -- 在探测时通过 rmi_input_configured（） 无条件达到 -- 存储 writeReport[4]，rmi_hid_read_block（） 存储 writeReport[0..5]。由于 readReport 位于 writeReport + output_report_size，这些存储也会损坏下一个回复进行解析的窗口。读取路径更糟糕：复制长度来自设备填充的 readReport[1]，最多可达 255，副本从 &readReport[2] 开始，不考虑input_report_size，因此它会超过分配的末尾运行到相邻的 slab 对象中。这甚至不需要躺着的设备 -- rmi_f01_probe（） 会发出固定的 21 字节寄存器读取，因此任何宣告输入报告小于 23 字节的设备都会越界读取，即使其如实应答也是如此。这些字节成为 RMI 核心作用于的寄存器值：
    rmi_f01_probe（） 将其作为产品 ID 打印到内核日志，并通过同名的模式 0444 sysfs 属性导出，rmi_driver_set_irq_bits（） 将它们作为中断掩码发送回设备，因此过小的报告描述符会将堆内容泄漏至非特权用户空间和设备本身。写入路径也没有边界：rmi_hid_write_block（） 将一个无限的 len 复制到 &writeReport[4]，设备在探测时可以驱动的最大调用程序是 rmi_driver_set_irq_bits（），其长度来自设备在其页面描述表中声明的中断源计数。最后，读取循环不能在零长度回复时终止：此类回复不复制任何内容，既不bytes_read也不前进bytes_needed，并且由于回复确实到达了 1 秒 wait_event_timeout（） 也不触发，因此回答 0 的设备永远保持循环在探测工作线程中运行，并保留page_mutex。khungtaskd 不会注意到，因为每个回复都会唤醒任务。
    拒绝对驱动程序所构建内容而言太小的报告 -- 6 个输出字节用于写入报告，3 个输入字节用于读取握手 -- 在探测时，将写入和读取副本限制到报告大小到设备声明的大小，并将零长度回复视为错误。以此方式拒绝的设备将作为普通 HID 设备启动，例如完全不携带 RMI 报告 ID 的设备。该路径上不得将 RMI_DEVICE 保留在 device_flags 中设置，因为 rmi_input_configured（） 随后将运行 RMI 设置并到达 rmi_set_page（），后者会写入 writeReport 缓冲区，而该缓冲区刚刚略过了分配。该位可以到达 set：rmi_probe（） 在报告检查之前将 id->driver_data 复制到 device_flags，通过 new_id sysfs 属性的绑定可提供具有RMI_DEVICE （BIT（0）） 集的driver_data。剥离复制driver_data处的位，以便RMI_DEVICE继续表示此探测验证了报告;还涵盖了此修补程序之前的三个启动跳转。错误路径还清除了RMI_READ_DATA_PENDING，因为该标志是循环顶部的等待测试的内容：
    保持该设置将使每个后续的 wait_event_timeout（） 在过时回复中立即返回，并在设备的剩余生命周期内终止读取路径。钳制不会回归工作硬件：读取循环已处理 ---truncated--- （CVE-2026-90000）

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - HID:rmi:サイズの小さい RMI レポートでの OOB アクセスを修正します hid-rmi ドライバーは、writeReport/readReport バッファのサイズを、純粋にデバイスから提供されたレポート記述子から、最小バインドなしで設定します:
    データ>input_report_size = hid_report_len(input_report);データ>output_report_size = hid_report_len(output_report);alloc_size = データ>output_report_size + データ>input_report_size;
    data->writeReport = devm_kzalloc(&hdev->dev、alloc_size、GFP_KERNEL);data->readReport = data->writeReport + data->output_report_size;しかし、その後、固定オフセットを読み書きします。1 バイトの出力と 1 バイトの入力レポートを宣言するデバイスは、hid_report_len() にそれぞれ 2 つを返すようにするため、alloc_size 4 となりますが、rmi_set_page() は -- rmi_input_configured() を通じてプローブタイムに無条件に到達した -- は writeReport[4] を保存し、 rmi_hid_read_block() は writeReport[0..5] を保存します。readReport は writeReport + output_report_size に存在するため、これらのストアはまた、次の返信を解析する際にウィンドウを破損します。コピーの長さは readReport[1] から来ます。デバイスがこれを入力して最大 255 になる可能性があり、コピーは input_report_sizeに関係なく &readReport[2] で始まるため、隣接するスラブオブジェクトへの割り当ての終わりを超えて実行します。これには嘘つきデバイスすら必要ありません -- rmi_f01_probe() は固定 21 バイトのレジスター読み取りを発行します。したがって、23 バイト未満の入力レポートを宣言するデバイスは、たとえ真実に従って応答したとしても、領域外読み取りを行います。これらのバイトは、RMI コアが作用するレジスタ値になります。
    rmi_f01_probe() は、これらを製品 ID としてカーネルログに出力し、同じ名前のモード 0444 sysfs 属性を通してエクスポートします。rmi_driver_set_irq_bits() は、これらを割り込みマスクとしてデバイスに送り返します。これにより、サイズの小さいレポート記述子が、ヒープコンテンツを権限のないユーザー空間とデバイス自体の両方に漏洩します。書き込みパスにはバインドもありません:rmi_hid_write_block()は無制限のlenを&writeReport[4]にコピーし、プローブ時にデバイスが駆動できる最大の呼び出し元はrmi_driver_set_irq_bits()であり、その長さはデバイスがそのPage Description Tableで宣言する割り込みソースカウントから派生します。最後に、読み取りループは長さがゼロの返信で終了することはできません。そのような返信は何もコピーせず、bytes_readもbytes_neededも進まず、また、返信が到着したため、1秒のwait_event_timeout()も起動しないため、デバイスが0を永遠に応答すると、page_mutexを保持したままプローブワーカー内でループが実行され続けます。返信するたびにタスクがスリープ解除されるため、khungtaskd は気づきません。
    ドライバーが構築するものに対して小さすぎるレポートを拒否します -- 書き込みレポートに 6 出力バイト、読み取りハンドシェイクに 3 入力バイト -- プローブ時に書き込みコピーと読み取りコピーをデバイスが宣言したレポートサイズに固定し、長さがゼロの返信をエラーとして扱います。この方法で拒否されたデバイスは、RMI レポート ID をまったく伝送しないデバイスなどの通常の HID デバイスとして起動されます。RMI_DEVICE はそのパスで device_flags に設定されたままにしてはなりません。これは、rmi_input_configured() が RMI セットアップを実行し、rmi_set_page() に到達します。() は、拒否が割り当てをスキップしたばかりの writeReport バッファを書き込むためです。ビットはセットに到着できます:rmi_probe()はレポートチェックの前にid->driver_dataをdevice_flagsにコピーし、new_id sysfs属性を通じたバインドはRMI_DEVICE(BIT(0))セットをdriver_dataに供給できます。driver_dataがコピーされたビットを取り除いて、このプローブがレポートを検証したと正確に意味RMI_DEVICE保たれます。このパッチより前の 3 つの jump to start についてもカバーします。また、そのフラグはループの先頭での待機がテストするものであるため、エラーパスはRMI_READ_DATA_PENDINGをクリアします。
    設定のままにしておくと、その後のwait_event_timeout()は古い返信をすぐに返してしまい、デバイスの残りの寿命の間に読み取りパスを強制終了します。クランプは作業ハードウェアを回帰しません:読み取りループはすでに ---truncated--- を処理しています(CVE-2026-90000)

Nessus は、ベンダーから報告されたパッケージの存在に依存していることに注意してください。

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - 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-2026-90000)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
346573	Linux Distros 未修補弱點：CVE-2026-90000	Nessus	Misc.	2026/9/16	2026/9/18	high
346573	Linux Distros 未修补的漏洞：CVE-2026-90000	Nessus	Misc.	2026/9/16	2026/9/18	high
346573	Linux Distros のパッチ未適用の脆弱性: CVE-2026-90000	Nessus	Misc.	2026/9/16	2026/9/18	high
346573	Linux Distros Unpatched Vulnerability : CVE-2026-90000	Nessus	Misc.	2026/9/16	2026/9/18	high

检测

插件搜索

high

high

high

high