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

  - mfd：qnap-mcu：在命令超时后保持回复缓冲区活动 qnap_mcu_exec（） 向接收路径发布堆栈上的缓冲区：unsigned char rx[QNAP_MCU_RX_BUFFER_SIZE];...回复 >data = rx;reply->length = 长度;qnap_mcu_receive_buf（） 从 serdev 接收路径写入其中，该路径耗尽了 flush_to_ldisc（） 并且完全不会针对 qnap_mcu_exec（） 进行序列化。bus_lock无法覆盖它，因为 qnap_mcu_exec（） 跨 wait_for_completion_timeout（） 保留该互斥体。超时时，qnap_mcu_exec（） 返回时 reply->data 仍指向自己的帧。然后，迟到的回复或来自 MCU 的未经请求的消息会被写入剩下的堆栈帧，从而损坏该堆栈上接下来运行的任何内容。当 qnap_mcu_write（） 失败时，这同样适用，因为该路径也不会触及回复状态而返回。将接收缓冲区移动至 struct qnap_mcu。它有 37 个字节，并且结构是 devm_kzalloc（） 处理的，因此它的有效期与驱动程序一样长，并且延迟写入到仍然有效并由下一个命令重新初始化的内存中。bus_lock阻止命令共享它。这故意不清除超时路径中的 reply->data 或 reply->length。这样做会与 qnap_mcu_receive_buf（） 争用，后者在其 if （！reply->length） 返回大小之后读取两者;check：清除 reply->data 会造成空取消引用，单独清除 reply->length 会删除 reply->received == reply->length 退出条件，因此复制循环一直运行，直到消耗完 uart 区块并溢出缓冲区。保留这两个集合会保持写入受 reply->length 限制，qnap_mcu_exec（） 已根据 sizeof（mcu->rx） 进行检查。
    (CVE-2026-80975)

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

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

  - mfd： qnap-mcu：在命令逾時後保持回覆緩衝區處於活動狀態 qnap_mcu_exec（） 會將堆疊上緩衝區發佈至接收路徑：unsigned char rx[QNAP_MCU_RX_BUFFER_SIZE];...回覆 >data = rx;reply->length = 長度;並且 qnap_mcu_receive_buf（） 從 serdev 接收路徑寫入其中，該路徑耗盡了 flush_to_ldisc（），並且根本不會針對 qnap_mcu_exec（） 進行序列化。bus_lock無法覆蓋它，因為 qnap_mcu_exec（） 跨 wait_for_completion_timeout（） 保留該互斥體。逾時時，qnap_mcu_exec（） 傳回 reply->data 仍指向自己的框架。然後，遲到的回覆或來自 MCU 的主動訊息會寫入已留下的堆疊框架中，從而損壞該堆疊上接下來執行的任何內容。當 qnap_mcu_write（） 失敗時，這同樣適用，因為該路徑返回時也不會觸及回覆狀態。將接收緩衝區移至結構qnap_mcu。它是 37 位元組，結構是 devm_kzalloc（）ed，因此它的存續時間與驅動程式一樣長，並且延遲寫入仍然有效的記憶體中，並由下一個命令重新初始化。bus_lock防止命令共用它。這會刻意不清除逾時路徑上的 reply->data 或 reply->length。這樣做會與 qnap_mcu_receive_buf（） 爭用，後者在其 if （！reply->length） 傳回大小之後讀取兩者;檢查：清除 reply->data 會提供 NULL 解除參照，而僅清除 reply->length 會移除 reply->received == reply->length 結束條件，因此複製迴圈會一直執行，直到 UART 區塊被消耗並溢出緩衝區為止。保留這兩個集合會使寫入受 reply->length 的限制，qnap_mcu_exec（） 已經根據 sizeof（mcu->rx） 檢查了該長度。
    (CVE-2026-80975)

請注意，Nessus 依賴供應商報告的套件存在。

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

  - MFD:qnap-mcu:コマンドタイムアウトを過ぎても返信バッファをアライブ状態に保ちます qnap_mcu_exec() は、受信パスに対してスタック上のバッファを公開します: unsigned char rx[QNAP_MCU_RX_BUFFER_SIZE];...reply->data = rx;reply->length = 長さ;qnap_mcu_receive_buf() は serdev 受信パスから書き込みますが、これは flush_to_ldisc() を使い果たし、qnap_mcu_exec() に対してまったくシリアル化されません。qnap_mcu_exec()はwait_for_completion_timeout()間でそのmutexを保持するため、bus_lockはそれをカバーできません。タイムアウト時に、qnap_mcu_exec() が返信>データを返しますが、依然としてそれ自体のフレームをポイントしています。遅れて到着した応答、または MCU からの一方的なメッセージは、残されたスタックフレームに書き込まれ、そのスタック上で次に実行されるものをすべて破損します。qnap_mcu_write()が失敗した場合も同様で、そのパスは返信状態に触れずに返されるためです。受信バッファを構造体qnap_mcuに移動します。これは 37 バイトで、構造体が devm_kzalloc()ed であるため、ドライバーと同じくらい存続し、遅延書き込みがまだ有効で次のコマンドによって再初期化されるメモリに着地します。bus_lock、コマンドが共有されないようにします。これにより、タイムアウトパス上の reply->data または reply->length が意図的に消去されません。これを行うと、if(!reply->length)の戻り値サイズの後に両方を読み取るqnap_mcu_receive_buf()と競合します。確認:reply->data をクリアすると NULL 逆参照が行われ、reply->length のみをクリアすると reply->received == reply->length 終了状態が削除されるため、uart チャンクが消費されバッファオーバーランになるまで、コピーループが実行されます。両方のセットのままにしておくと、書き込みがreply->lengthに制限されたままになります。これは、qnap_mcu_exec()がsizeof(mcu->rx)に対してすでにチェックしています。
    (CVE-2026-80975)

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

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

  - In the Linux kernel, the following vulnerability has been resolved: mfd: qnap-mcu: keep the reply buffer     alive past a command timeout qnap_mcu_exec() publishes an on-stack buffer to the receive path: unsigned     char rx[QNAP_MCU_RX_BUFFER_SIZE]; ... reply->data = rx; reply->length = length; and qnap_mcu_receive_buf()     writes into it from the serdev receive path, which runs out of flush_to_ldisc() and is not serialized     against qnap_mcu_exec() at all. bus_lock cannot cover it, because qnap_mcu_exec() holds that mutex across     wait_for_completion_timeout(). On a timeout qnap_mcu_exec() returns with reply->data still pointing at its     own frame. A reply that arrives late, or an unsolicited message from the MCU, is then written into a stack     frame that has been left, corrupting whatever runs next on that stack. The same applies when     qnap_mcu_write() fails, since that path returns without touching the reply state either. Move the receive     buffer into struct qnap_mcu. It is 37 bytes and the structure is devm_kzalloc()ed, so it lives as long as     the driver, and a late write lands in memory that is still valid and is reinitialized by the next command.
    bus_lock keeps commands from sharing it. This deliberately does not clear reply->data or reply->length on     the timeout path. Doing so races with qnap_mcu_receive_buf(), which reads both after its if     (!reply->length) return size; check: clearing reply->data gives a NULL dereference, and clearing     reply->length alone removes the reply->received == reply->length exit condition, so the copy loop runs     until the uart chunk is consumed and overruns the buffer. Leaving both set keeps the write bounded by     reply->length, which qnap_mcu_exec() has already checked against sizeof(mcu->rx). (CVE-2026-80975)

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

ID	名稱	產品	系列	已發布	已更新	嚴重性
345212	Linux Distros 未修补的漏洞：CVE-2026-80975	Nessus	Misc.	2026/9/12	2026/11/10	high
345212	Linux Distros 未修補弱點：CVE-2026-80975	Nessus	Misc.	2026/9/12	2026/11/10	high
345212	Linux Distros のパッチ未適用の脆弱性: CVE-2026-80975	Nessus	Misc.	2026/9/12	2026/11/10	high
345212	Linux Distros Unpatched Vulnerability : CVE-2026-80975	Nessus	Misc.	2026/9/12	2026/11/10	high
376443	Ubuntu 24.04 LTS / 26.04 LTS : Linux kernel vulnerabilities (USN-8959-1)	Nessus	Ubuntu Local Security Checks	2026/11/5	2026/11/5	high

偵測

搜尋 Plugin

high

high

high

high

high