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

  - net：ipa：修复运行时恢复后停止的调制解调器 TX 队列 ipa_start_xmit（） 在调用 pm_runtime_get（） 之前无条件停止 TX 队列，并依靠运行时恢复 （ipa_modem_wake_queue_work（）） 计划的唤醒在电源激活时重新启动它。但是，在设备的电源状态达到RPM_ACTIVE之前，该工作会从运行时恢复回调中排队，因此它可以在设备仍处于RPM_RESUMING状态时运行。然后唤醒过早消耗：它重新启动的传输再次停止队列，pm_runtime_get（） 返回 -EINPROGRESS 而不安排任何未来的唤醒（deferred_resume仅对 RPM_SUSPENDING 存在），并且恢复完成后，没有任何东西可以唤醒队列。
    传输永久停止：数据包堆积在已停止队列后面的 qdisc 中，设备运行时暂停，并且由于 netdev 未注册任何ndo_tx_timeout监视程序从不触发。在 （Fairphone 6） 上 SM7635 观察到蜂窝数据路径在数小时内永久失聪，包括 RX，因为没有任何东西可以恢复挂起的端点。在唤醒队列之前，通过使唤醒工作等待恢复完成 （pm_runtime_get_sync（）） 来关闭窗口。然后保证每次队列停止都会在电源处于活动状态时发生的稍后唤醒;与新的暂停/恢复周期争用的传输会重新调度工作。如果设备无法恢复，请始终唤醒队列，以便传输路径丢弃待定数据包，而不是搁浅。STARTED 电源标志用于缩小此窗口范围：在发射路径停止之前运行的唤醒会抑制该停止，但仅抑制一次，因为该标志被它吸收的第一个停止清除。在飞行中恢复期间，移除该标志的单个传输足以搁浅队列，这就是观察到的形式。使用加速复制器（自动暂停延迟缩短至 5 毫秒，~20 个数据包/秒的 TX），未经修补的内核在 230 秒/4380 个数据包中停止了 3 次;通过此修补程序，同一测试运行了 3601 s / 70298 数据包而不会出现停止。（CVE-2026-80997）

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

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

  - net： ipa：在執行階段還原後修正停滯的數據機 TX 佇列 ipa_start_xmit（） 在呼叫 pm_runtime_get（） 之前無條件停止 TX 佇列，依靠執行階段還原 （ipa_modem_wake_queue_work（）） 排程的喚醒在電源啟用時重新啟動它。但是，在裝置的電源狀態達到RPM_ACTIVE之前，該工作會從執行階段繼續回呼內排入佇列，因此可以在裝置仍處於RPM_RESUMING狀態時執行。然後，喚醒過早被消耗：它重新啟動的傳輸再次停止佇列，pm_runtime_get（） 返回 -EINPROGRESS，而不安排任何未來的喚醒（deferred_resume僅存在於RPM_SUSPENDING），並且在恢復完成後，沒有任何東西可以喚醒佇列。
    傳輸永久停止：封包堆積在停止佇列後面的 qdisc 中，裝置運行時暫停，並且由於 netdev 未註冊任何ndo_tx_timeout因此監控程式永遠不會觸發。在 （Fairphone 6） 上 SM7635 觀察到蜂窩數據路徑在數小時內永久失聰，包括 RX，因為沒有任何東西可以恢復暫停的端點。在喚醒佇列之前，讓喚醒工作等待繼續完成 （pm_runtime_get_sync（）），以關閉視窗。然後保證每次佇列停止都會在電源處於作用中狀態時發生稍後的喚醒;競用新的暫停/恢復週期的傳輸會重新安排工作。如果裝置無法繼續，請無論如何喚醒佇列，以便傳輸路徑捨棄擱置中的封包，而不是擱淺。STARTED 電源旗標用來縮小此視窗：在傳輸路徑停止之前執行的喚醒會抑制該停止，但只有一次，因為旗標已被它吸收的第一個停止清除。移除旗幟會在飛行中恢復期間進行一次傳輸，足以擱淺隊列，這就是觀察到的形式。使用加速重現器 （自動暫停延遲縮短至 5 毫秒，~20 封包/秒的 TX），未修補的核心在 230 秒 / 4380 封包中停頓了 3 次;使用此修補程式時，相同的測試運行了 3601 s / 70298 封包，沒有停止。（CVE-2026-80997）

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

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

  - net:ipa:ランタイム再開後のストール状態のモデム TX キューを修正します ipa_start_xmit() は pm_runtime_get() を呼び出す前に無条件に TX キューを停止し、ランタイム再開(ipa_modem_wake_queue_work())でスケジュールされたウェイクに依存して、電源がアクティブになると再起動します。ただし、その作業は、デバイスの電源状態がRPM_ACTIVEに達する前に、ランタイム再開コールバック内からキューに入れられるため、デバイスがまだRPM_RESUMINGている間に実行できます。その後、ウェイクの消費が早すぎます。再起動する送信によりキューが再び停止され、pm_runtime_get() が将来のウェイクを手配せずに -EINPROGRESS を返し (deferred_resumeは RPM_SUSPENDING にのみ存在します)、再開が完了した後、キューをウェイク解除するものは何も残りません。
    送信が恒久的にストールします:パケットが停止されたキューの後ろの qdisc に蓄積され、デバイスのランタイムが一時停止します。また、netdev がndo_tx_timeoutを登録しないため、ウォッチドッグは決して起動しません。SM7635(Fairphone 6)では、セルラーデータパスが数時間以内に永久に聴覚不能になることが観測されました(RXも含む)。これは、中断されたエンドポイントを何も再開しないためです。キューをウェイクアップする前に、ウェイクワークにレジュームが完了するまで待機(pm_runtime_get_sync())させて、ウィンドウを閉じます。その後、すべてのキューの停止は、電源がアクティブである間に発生する後のウェイクが保証されます。新しい中断/再開サイクルを競合している送信は、作業のスケジュールを変更します。デバイスが再開できなかった場合は、保留中のパケットがストランドされるのではなく伝送パスによりドロップされるように、キューをスリープ解除してください。STARTED 電源フラグは、このウィンドウを狭めるために使用されました:送信パスの停止の前に実行中のウェイクは、その停止を抑制しましたが、フラグが吸収した最初の停止によってクリアされたため、1 回のみでした。フラグを削除すると、インフライトの再開中の 1 回の送信が、観測されたフォームでキューをストランドするのに十分になりました。加速されたリプリケーター(オートサスペンドの遅延が 5 ms、~20 packet/s の TX に短縮された)では、パッチ未適用のカーネルが 230 秒 / 4380 パケットで 3 回ストールしました。このパッチを使用することで、同じテストで 3601 s / 70298 パケットがストールすることなく実行されました。(CVE-2026-80997)

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

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

  - net: ipa: fix stalled modem TX queue after runtime resume ipa_start_xmit() unconditionally stops the TX     queue before calling pm_runtime_get(), relying on the wake scheduled by runtime resume     (ipa_modem_wake_queue_work()) to restart it once power is ACTIVE. But that work is queued from within the     runtime resume callback, before the device's power state reaches RPM_ACTIVE, so it can run while the     device is still RPM_RESUMING. The wake is then consumed too early: the transmit it restarts stops the     queue again, pm_runtime_get() returns -EINPROGRESS without arranging any future wake (deferred_resume     exists only for RPM_SUSPENDING), and after the resume completes nothing is left to wake the queue.
    Transmit stalls permanently: packets pile up in the qdisc behind the stopped queue, the device runtime-     suspends, and since the netdev registers no ndo_tx_timeout the watchdog never fires. Observed on SM7635     (Fairphone 6) as the cellular data path going permanently deaf within hours, RX included, since nothing     resumes the suspended endpoints. Close the window by making the wake work wait for the resume to complete     (pm_runtime_get_sync()) before waking the queue. Every queue stop is then guaranteed a later wake that     happens while power is ACTIVE; a transmit racing a new suspend/resume cycle re-schedules the work. If the     device could not be resumed, wake the queue anyway so pending packets are dropped by the transmit path     rather than stranded. The STARTED power flag used to narrow this window: a wake running before the     transmit path's stop suppressed that stop, but only once, as the flag was cleared by the first stop it     absorbed. Removing the flag made a single transmit during an in-flight resume sufficient to strand the     queue, which is the form observed. With an accelerated reproducer (autosuspend delay shortened to 5 ms,     ~20 packets/s of TX), an unpatched kernel stalled three times in 230 s / 4380 packets; with this patch the     same test ran 3601 s / 70298 packets without a stall. (CVE-2026-80997)

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

ID	Name	Product	Family	Published	Updated	Severity
345381	Linux Distros 未修补的漏洞：CVE-2026-80997	Nessus	Misc.	9/12/2026	9/14/2026	high
345381	Linux Distros 未修補弱點：CVE-2026-80997	Nessus	Misc.	9/12/2026	9/14/2026	high
345381	Linux Distros のパッチ未適用の脆弱性: CVE-2026-80997	Nessus	Misc.	9/12/2026	9/14/2026	high
345381	Linux Distros Unpatched Vulnerability : CVE-2026-80997	Nessus	Misc.	9/12/2026	9/14/2026	high

Detections

Analytics

Plugins Search

high

high

high

high